From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: VT-d support for device assignment Date: Sat, 23 Aug 2008 12:33:46 +0300 Message-ID: <48AFD97A.30309@qumranet.com> References: <1219389054-15332-1-git-send-email-amit.shah@qumranet.com> <48AF039B.7040805@qumranet.com> <200808231442.09332.amit.shah@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, muli@il.ibm.com, anthony@codemonkey.ws, jesse.barnes@intel.com, david.woodhouse@intel.com, mark.gross@intel.com, benami@il.ibm.com, weidong.han@intel.com To: Amit Shah Return-path: Received: from il.qumranet.com ([212.179.150.194]:18751 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752097AbYHWJdo (ORCPT ); Sat, 23 Aug 2008 05:33:44 -0400 In-Reply-To: <200808231442.09332.amit.shah@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: Amit Shah wrote: > * On Friday 22 Aug 2008 23:51:15 Avi Kivity wrote: > >> Amit Shah wrote: >> >>> The following two patches contain VT-d support for device assignment >>> for KVM guests. >>> >>> The first patch contains the changes that are required to the generic >>> VT-d code. >>> >>> The second patch contains the changes to KVM. >>> >>> I've updated the 2nd patch to use VT-d only when requested by a parameter >>> on the command line, making it easier to support iommu with pvdma and >>> multiple iommu types. >>> >>> The command line currently should be invoked as: >>> >>> -pcidevice dev=00:13.0,vtd=on >>> >> You mean, iommu=on. >> > > I did mean vtd=on, since we'll also have AMD's iommu implementation here. > > So something like: > > -pcidevice dev=00:13.0,vtd=on,pvdma=on > > or > > -pcidevice dev=00:13.0,amd-iommu=on,pvdma=on > > or do you mean we should autodetect which IOMMU we have and then select the > appropriate one instead of bothering the user with it? Hmm, that seems a > better UI and also such startup scripts can be ported across architectures. > > Yes of course. Note there's no need for kvm to autodetect the iommu either; I won't let the amd iommu in without a proper abstraction via an iommu api. >> Or rather >> >> dma=iommu >> dma=none (1:1 mapping, or dma-less devices, or I'm Feeling Lucky) >> dma=cooperative (paravirt) >> > > This looks much better! > > Once we have KVM_CAP_VTD, KVM_CAP_AMD_IOMMU and KVM_CAP_PVDMA, > Why KVM_CAP_VTD and KVM_CAP_AMD_IOMMU? Do they actually have differences? if so, the capabilities should report the differences as features, not as vendor identifiers. > dma=iommu means use either of VTD or AMD, whichever one is available > dma=none means I'm feeling lucky > > PVDMA will automatically get used if the guest has PVDMA support compiled in. > Enabling/disabling pvdma would be a guest option rather than a host option, I > think (host only exposes CAP_PVDMA). > > Is this ok? > So long as there is no potential for performance or security impact, having pvdma turned on automatically is better. We could still have dma=noparavirt to disable it. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.