From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: device assignemnt: updated patches Date: Sat, 26 Jul 2008 12:32:37 +0300 Message-ID: <488AEF35.10909@qumranet.com> References: <1216728835-19721-1-git-send-email-benami@il.ibm.com> <488AE8ED.2010301@qumranet.com> <0122C7C995D32147B66BF4F440D30163016E822A@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben-Ami Yassour , amit.shah@qumranet.com, kvm@vger.kernel.org, muli@il.ibm.com, anthony@codemonkey.ws To: "Han, Weidong" Return-path: Received: from il.qumranet.com ([212.179.150.194]:51200 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbYGZJci (ORCPT ); Sat, 26 Jul 2008 05:32:38 -0400 In-Reply-To: <0122C7C995D32147B66BF4F440D30163016E822A@pdsmsx415.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Han, Weidong wrote: >> How are we standing with merging the changes to the VT-d driver, which >> are a prerequisite? >> > > You mean push the changes into VT-d driver first. But the VT-d driver > modification patch maybe need some changes during following development. > How about making it stable in KVM first, then push it into VT-d driver? > Yeah, we do have a chicken-and-egg situation here. I guess I can carry that patch while we're working this out. Longer term, we will have to move to a vendor neutral API so as to support amd iommu and non-x86 iommus. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.