From: Marcel Apfelbaum <marcel@redhat.com>
To: Peter Xu <peterx@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pcie-root-port: let it has higher migrate priority
Date: Fri, 2 Feb 2018 14:39:48 +0200 [thread overview]
Message-ID: <b1ba0462-96ec-463e-f7fa-062e1b04638f@redhat.com> (raw)
In-Reply-To: <20180202095643.GA4666@xz-mi>
On 02/02/2018 11:56, Peter Xu wrote:
> On Thu, Feb 01, 2018 at 07:51:31PM +0000, Dr. David Alan Gilbert wrote:
>> * Peter Xu (peterx@redhat.com) wrote:
>>> In the past, we prioritized IOMMU migration so that we have such a
>>> priority order:
>>>
>>> IOMMU > PCI Devices
>>>
>>> When migrating a guest with both vIOMMU and pcie-root-port, we'll always
>>> migrate vIOMMU first, since pcie-root-port will be seen to have the same
>>> priority of general PCI devices.
>>>
>>> That's problematic.
>>>
>>> The thing is that PCI bus number information is stored in the root port,
>>> and that is needed by vIOMMU during post_load(), e.g., to figure out
>>> context entry for a device. If we don't have correct bus numbers for
>>> devices, we won't be able to recover device state of the DMAR memory
>>> regions, and things will be messed up.
>>>
>>> So let's boost the PCIe root ports to be even with higher priority:
>>>
>>> PCIe Root Port > IOMMU > PCI Devices
>>>
>>> A smoke test shows that this patch fixes bug 1538953.
>>
>> Two questions (partially overlapping with what I replied to Michaels):
>> a) What happens with multiple IOMMUs?
>
> If there are more IOMMUs, then the patch will let all the vIOMMUs be
> migrated after pcie root ports.
>
> But a more true answer is that: I don't really know. :)
>
> Because I even don't know how multiple vIOMMUs will coop with each
> other, especially nested.
I am not aware of "nested" IOMMUs. Multiple IOMMUs work together
by dividing the bus ranges, when each of them declares in the
corresponding ACPI table the bus/device/range is in charge of.
However there was a kernel bug some time ago preventing several
IOMMUs to work together, I am not sure the problem is solved yet.
In nested case, maybe there will be
> dependency between vIOMMUs, but I'll avoid thinking about that until
> we support more than one vIOMMUs.
>
>> b) What happens with multiple root ports?
>
> Same answer as previous one: all of them will be migrated before any
> vIOMMUs.
>
> Note that IMHO we don't care which pcie root port is migrated first -
> IMHO they should not depend on each other, but Marcel may correct me.
>
Right, each Root Port is independent from each other.
Thanks,
Marcel
>> c) How correct is this ordering on different implementations
>> (e.g. ARM/Power/etc)
>
> Currently it won't affect since Intel IOMMU is the only user for
> MIG_PRI_IOMMU. After SMMU is merged it may affect (if it uses this
> bit), but IMHO it's fine too as long as pcie root ports won't depend
> on anything related to SMMU.
>
> Thanks,
>
prev parent reply other threads:[~2018-02-02 16:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 11:20 [Qemu-devel] [PATCH] pcie-root-port: let it has higher migrate priority Peter Xu
2018-02-01 12:24 ` Marcel Apfelbaum
2018-02-01 19:18 ` Michael S. Tsirkin
2018-02-01 19:48 ` Dr. David Alan Gilbert
2018-02-01 20:01 ` Marcel Apfelbaum
2018-02-01 20:10 ` Dr. David Alan Gilbert
2018-02-02 10:04 ` Peter Xu
2018-02-02 13:25 ` Marcel Apfelbaum
2018-02-01 19:38 ` Dr. David Alan Gilbert
2018-02-02 10:19 ` Peter Xu
2018-02-01 19:51 ` Dr. David Alan Gilbert
2018-02-02 9:56 ` Peter Xu
2018-02-02 12:39 ` Marcel Apfelbaum [this message]
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=b1ba0462-96ec-463e-f7fa-062e1b04638f@redhat.com \
--to=marcel@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).