* On Saturday 23 Aug 2008 15:03:46 Avi Kivity wrote: > 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.
Yes; we're going to have an API once the Intel IOMMU support goes in. > >> 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. Agreed. > > 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. So we fail the hypercalls once the guest tries to contact us? Amit -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
