[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] enable iommu with -device
Date: Thu, 2 Jun 2016 23:30:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

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

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

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


-- peterx

reply via email to

[Prev in Thread] Current Thread [Next in Thread]