* 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. > 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, 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? 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
