From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Remaining passthrough/VT-d tasks list Date: Sun, 28 Sep 2008 07:22:53 +0300 Message-ID: <48DF069D.90004@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> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 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: "Tian, Kevin" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:34402 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbYI1EXW (ORCPT ); Sun, 28 Sep 2008 00:23:22 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Tian, Kevin wrote: >> >> 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. >> >> > > This issue also exists on host side, that one misbehaved driver > can hurt all other drivers sharing same irq line. There is no issue on the host, since all drivers operate on the same trust level. A misbehaving driver on the host will take down the entire system even without shared interrupts, by corrupting memory, not releasing a lock, etc. But if you move a driver to the guest, you expect it will be isolated from the rest of the system, and if there are shared interrupts, it isn't. > But it seems no > good way to avoid it. Since not all devices support MSI, we still > need support irq sharing possibly with above caveats given. > > Existing approach at least works with a sane guest driver, with > some performance penality there. > > How can we recommend it to users? We tell them, your guests are isolated and secure as long as they don't misbehave? > Or do you have better alternative? > No. Maybe the Neocleus polarity trick (which also reduces performance). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.