From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
Eric Auger <eric.auger@redhat.com>
Cc: virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org
Subject: virtio-iommu hotplug issue
Date: Thu, 13 Apr 2023 13:49:43 +0900 [thread overview]
Message-ID: <15bf1b00-3aa0-973a-3a86-3fa5c4d41d2c@daynix.com> (raw)
Hi,
Recently I encountered a problem with the combination of Linux's
virtio-iommu driver and QEMU when a SR-IOV virtual function gets
disabled. I'd like to ask you what kind of solution is appropriate here
and implement the solution if possible.
A PCIe device implementing the SR-IOV specification exports a virtual
function, and the guest can enable or disable it at runtime by writing
to a configuration register. This effectively looks like a PCI device is
hotplugged for the guest. In such a case, the kernel assumes the
endpoint is detached from the virtio-iommu domain, but QEMU actually
does not detach it.
This inconsistent view of the removed device sometimes prevents the VM
from correctly performing the following procedure, for example:
1. Enable a VF.
2. Disable the VF.
3. Open a vfio container.
4. Open the group which the PF belongs to.
5. Add the group to the vfio container.
6. Map some memory region.
7. Close the group.
8. Close the vfio container.
9. Repeat 3-8
When the VF gets disabled, the kernel assumes the endpoint is detached
from the IOMMU domain, but QEMU actually doesn't detach it. Later, the
domain will be reused in step 3-8.
In step 7, the PF will be detached, and the kernel thinks there is no
endpoint attached and the mapping the domain holds is cleared, but the
VF endpoint is still attached and the mapping is kept intact.
In step 9, the same domain will be reused again, and the kernel requests
to create a new mapping, but it will conflict with the existing mapping
and result in -EINVAL.
This problem can be fixed by either of:
- requesting the detachment of the endpoint from the guest when the PCI
device is unplugged (the VF is disabled)
- detecting that the PCI device is gone and automatically detach it on
QEMU-side.
It is not completely clear for me which solution is more appropriate as
the virtio-iommu specification is written in a way independent of the
endpoint mechanism and does not say what should be done when a PCI
device is unplugged.
Regards,
Akihiko Odaki
next reply other threads:[~2023-04-13 4:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 4:49 Akihiko Odaki [this message]
2023-04-13 10:40 ` virtio-iommu hotplug issue Jean-Philippe Brucker
2023-04-13 11:01 ` Akihiko Odaki
2023-04-13 13:39 ` Eric Auger
2023-04-14 2:51 ` Akihiko Odaki
2023-04-14 15:17 ` Jean-Philippe Brucker
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=15bf1b00-3aa0-973a-3a86-3fa5c4d41d2c@daynix.com \
--to=akihiko.odaki@daynix.com \
--cc=eric.auger@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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).