Re: [Qemu-devel] [PATCH RFC 0/2] enable iommu with -device

[Marcel Apfelbaum <marcel@redhat.com>]

On 05/31/2016 04:44 AM, Peter Xu wrote:
> On Mon, May 30, 2016 at 05:14:15PM +0300, Marcel Apfelbaum wrote:
>> On 05/30/2016 04:43 PM, Peter Xu wrote:
>>> On Mon, May 23, 2016 at 05:01:28PM +0300, Marcel Apfelbaum wrote:
>>>> This is a proposal on how to create the iommu with
>>>> '-device intel-iommu' instead of '-machine,iommu=on'.
>>>>
>>>> The device is part of the machine properties because we wanted
>>>> to ensure it is created before any other PCI device.
>>>>
>>>> The alternative is to skip the bus_master_enable_region at
>>>> the time the device is created. We can create this region
>>>> at machine_done phase. (patch 1)
>>>>
>>>> Then we can enable sysbus devices for PC machines and make all the
>>>> init steps inside the iommu realize function. (patch 2)
>>>>
>>>> The series is working, but a lot of issues are not resolved:
>>>>    - minimum testing was done
>>>>    - the iommu addr should be passed (maybe) in command line rather than hard-coded
>>>>    - enabling sysbus devices for PC machines is risky, I am not aware yet
>>>>      of the side effects of this modification.
>>>>    - I am not sure moving the bus_master_enable_region to machine_done
>>>>      is with no undesired effects.
>>>
>>> I gave it a shot on the patches and it works nicely (of course no
>>> complex configurations, like hot plug).
>>>
>>> Could you help introduce what will bring us if we use "-device" rather
>>> than "-M" options?  Benefits I can see is that, we can specify
>>> parameters with specific device, rather than messing them up in
>>> "machine" options. Do we have any other benefits that I may have
>>> missed?
>>
>> Hi Peter,
>> Thanks for trying it!
>>
>> Mainly is about not hard-coding device options (e.g. PCI address for AMD IOMMU),
>> but also to avoid having devices added as a side-effect of some machine option.
>> This will bring as closer to a cleaner model of a modular machine.
>>
>> I plan to post a non-rfc version soon.
>
> I just thought about whether we should support multiple IOMMUs in the
> future (never know whether there would be a use case for
> that).

This is an interesting scenario, we may find a need for multiple IOMMUs.
I tried it a while ago, but the linux kernel has (had?) a known limitation supporting it, see:
     https://lkml.org/lkml/2015/11/22/100
Since is categorized as bug, it may be solved and the we can go for it.

  Anyway, looking forward to your non-rfc version. :)

I just posted a new version.
Thanks,
Marcel

>


> Thanks!
>
> -- peterx
>