From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Remaining passthrough/VT-d tasks list Date: Sat, 27 Sep 2008 13:16:22 +0300 Message-ID: <48DE07F6.1080908@redhat.com> References: <0122C7C995D32147B66BF4F440D3016301C49E61@pdsmsx415.ccr.corp.intel.com> <200809241431.13571.sheng.yang@intel.com> <48D9FC8B.2040902@redhat.com> <200809271715.54439.sheng.yang@intel.com> <48DE01AB.2050303@redhat.com> <48DE0672.4060801@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Yang, Sheng" , "Han, Weidong" , "kvm@vger.kernel.org" , Amit Shah , "benami@il.ibm.com" , "muli@il.ibm.com" , "Kay, Allen M" , "Zhang, Xiantao" To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44608 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752139AbYI0KQl (ORCPT ); Sat, 27 Sep 2008 06:16:41 -0400 In-Reply-To: <48DE0672.4060801@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Avi Kivity wrote: > >> Yang, Sheng wrote: >> >>> After check host shared interrupts situation, I got a question here: >>> >>> If I understand correctly, current solution don't block host shared >>> irq, just come with the performance pentry. The penalty come with host >>> disabled irq line for a period. We have to wait guest to write EOI. >>> But I fail to see the correctness problem here (except a lot of >>> spurious interrupt in the guest). >>> >>> I've checked mail, but can't find clue about that. Can you explain the >>> situation? >>> >>> >>> >> If the guest fails to disable interrupts on a device that shares an >> interrupt line with the host, the host will experience an interrupt >> flood. Eventually the host will disable the host device as well. >> >> > > It's the same issue we have since ages in the real-time domain: You > cannot safely share IRQs between devices that are handled partly by > RT-safe and partly by RT-unsafe drivers. The only sane solution is to > write an RT-safe stub that is able to detect if an IRQ was triggered by > the non-RT device, satisfy the IRQ source (disable further IRQ > generation in the device), and forward the event to the non-RT driver > part for handling the rest later. > > Yes indeed -- exactly the same problem. > Transfered to the virtualization domain, you need a host driver stub for > each guest device that shares an IRQ with another host device. That will requires some communication between the guest driver and the host stub. > Maybe > there is some generic hardware support for this in recent PCI or in > VT-d, dunno. But that would simplify the stub development and > maintenance significantly. > > Using MSI works around the issue nicely, since interrupts are no longer shared. I imagine SR-IOV also fixes the issue. > BTW, uio's IRQ handling pattern is also related to this issue: A small, > device-specific IRQ receiver is written as a kernel driver while the > major driver code sits in user space and can handle the IRQ later - > without disturbing other devices sharing IRQs with the uio device. > This is yet another manifestation of the same issue. Those who understand computing are doomed to keep reinventing the wheel, badly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.