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.
--
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
