Re: VT-d support for device assignment

[Avi Kivity <avi@qumranet.com>]

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.