From: Peter Xu <peterx@redhat.com>
To: Marcel Apfelbaum <marcel@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
yi.l.liu@intel.com, qemu-devel@nongnu.org,
Jintack Lim <jintack@cs.columbia.edu>
Subject: Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize
Date: Thu, 2 Mar 2017 11:45:56 +0800 [thread overview]
Message-ID: <20170302034556.GL13926@pxdev.xzpeter.org> (raw)
In-Reply-To: <237f48d3-20eb-af1e-30ad-16a855607cdc@redhat.com>
On Wed, Mar 01, 2017 at 02:32:34PM +0200, Marcel Apfelbaum wrote:
> On 03/01/2017 11:59 AM, Peter Xu wrote:
> >On Wed, Mar 01, 2017 at 11:29:47AM +0200, Marcel Apfelbaum wrote:
> >>On 03/01/2017 11:18 AM, Peter Xu wrote:
> >>>On Wed, Mar 01, 2017 at 09:03:47AM +0200, Marcel Apfelbaum wrote:
> >>>>On 03/01/2017 06:14 AM, Jason Wang wrote:
> >>>
> >>>[...]
> >>>
> >>>>Hi Jason,
> >>>>
> >>>>I am not saying we don't need to create the IOMMU before some other device,
> >>>>I just don't think that the command line order should matter to user.
> >>>>
> >>>>BTW, are you working on a way to limit the IOMMU scope to a specific set of devices?
> >>>>If yes, this approach will also help you work.
> >>>
> >>>Marcel,
> >>>
> >>>Do you have any plan after 2.9 to re-arrange the init order thing a
> >>>bit? In general, maybe we need an ordering support for devices.
> >>
> >>I don;t know when I'll start it, but yes, I am thinking about
> >>taking this project. We need the ordering in order to be able
> >>to have less "built-in" devices.
> >
> >That'll be great!
> >
> >>
> >>>Besides that, I am thinking whether it would be wise that we just init
> >>>the IOMMUs during machine init just like before, but keep the
> >>>"-device" interface? After all, at least the root IOMMU device should
> >>>be with root complex, and it feels a little strange we just split the
> >>>init process apart (we delay the IOMMU init into device
> >>>initializations).
> >>>
> >>
> >>Keeping the IOMMU creation as part of the Root Complex is problematic.
> >>What happens if we want to limit the IOMMU scope to a subset of devices?
> >>How will the command line look? Also we may want/need multiple iommu
> >>devices per system. It will not happen tomorrow, but we don't want to loose
> >>this possibility.
> >
> >I think that won't be a big problem. E.g., I don't see big problem if
> >we just create all these vIOMMUs along with machine init. Is there?
> >
>
> How would you assign them do devices?
>
> The "normal" QEMU cmd line would look like I mentioned earlier:
>
> -device iommu,id=iommu1 -device pcie-root,iommu=iommu1 \
> -device pcie-root \
> -device iommu,id=iommu2 -device pcie-root,iommu=iommu2 \
>
> How do you propose to do it otherwise?
I totally agree that we can use the way above when we wants to bind
device with specific vIOMMU device. I was just wondering whether we
can move the init of "-device intel-iommu,..." to machine init phase,
no matter whether it's the vIOMMU on the root complex or not.
>
> >IMHO we can just pick these vIOMMU "devices" out of the device list,
> >and we can avoid doing that again in general device_init_func().
> >
> >>
> >>The device re-ordering is not 2.9 material of course, and we need your patch.
> >>The only thing we can do better is to take out the "vfio-pci" in another header
> >>file and and have it in a array of devices that should be checked
> >>(in order to avoid polluting the IOMMU code with a not related device)
> >>
> >>I can try and send a patch for it if you prefer.
> >
> >IMHO it'll be okay we "pollute" vtd code for a short while. We can
> >revert my patch (or any workarounds, like Jason's just posted one)
>
> Can you please send me a link to Jason's patch?
Sorry for the unclearness! This one:
https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg07844.html
I just posted v3 for this patch to co-op with Jason's patch.
Thanks,
-- peterx
next prev parent reply other threads:[~2017-03-02 3:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 4:29 [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize Peter Xu
2017-02-24 5:07 ` Pankaj Gupta
2017-02-24 5:50 ` Peter Xu
2017-02-24 6:35 ` Pankaj Gupta
2017-02-24 7:10 ` Peter Xu
2017-02-24 8:42 ` Pankaj Gupta
2017-02-28 14:42 ` Marcel Apfelbaum
2017-03-01 2:36 ` Peter Xu
2017-03-01 3:23 ` Michael S. Tsirkin
2017-03-01 4:14 ` Jason Wang
2017-03-01 7:03 ` Marcel Apfelbaum
2017-03-01 8:43 ` Jason Wang
2017-03-01 9:05 ` Marcel Apfelbaum
2017-03-01 9:18 ` Peter Xu
2017-03-01 9:29 ` Marcel Apfelbaum
2017-03-01 9:59 ` Peter Xu
2017-03-01 12:32 ` Marcel Apfelbaum
2017-03-02 3:45 ` Peter Xu [this message]
2017-03-02 3:39 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170302034556.GL13926@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jasowang@redhat.com \
--cc=jintack@cs.columbia.edu \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.