From: Jan Beulich <jbeulich@suse.com>
To: Scott Davis <scottwd@gmail.com>
Cc: Scott Davis <scott.davis@starlab.io>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
Paul Durrant <paul@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine
Date: Tue, 27 Apr 2021 08:56:28 +0200 [thread overview]
Message-ID: <cea1d2d0-fd69-a4cd-6653-dd881d07b96a@suse.com> (raw)
In-Reply-To: <0a292d952ff71dbfed5234d27b42a05f7b49a1fe.1619451434.git.scott.davis@starlab.io>
On 26.04.2021 19:25, Scott Davis wrote:
> This patch modifies Xen's behavior when making devices assignable while the
> iommu=no-quarantine command line option is in effect. Currently this option
> only affects device deassignment, causing devices to get immediately assigned
> back to Dom0 instead of to the quarantine dom_io domain. This patch extends
> no-quarantine to device assignment as well, preventing devices from being
> assigned to dom_io when they are made assignable while no-quarantine is in
> effect.
Well, the term "quarantine" to me means a safety action taken _after_
possible exposure to something "bad". Therefore I see this being specific
to device de-assignment as the logical thing. Hence if a mode like what
you describe was wanted, I don't think it should be the result of
"iommu=no-quarantine".
> First patch submission, apologies in advance for any formatting or other errors.
I couldn't spot any, except maybe ...
> Background: I am setting up a QEMU-based development and testing environment for
> the Crucible team at Star Lab that includes emulated PCIe devices for
> passthrough and hotplug. I encountered an issue with `xl pci-assignable-add`
> that causes the host QEMU to rapidly allocate memory until getting OOM-killed.
> I then found that the issue could be worked around either by using manual sysfs
> commands to rebind devices to pciback or by skipping over the quarantine logic
> in `libxl__device_pci_assignable_add`, producing a working system. I hoped that
> setting iommu=no-quarantine on the command line would have the same effect, only
> to be surprised that it did not.
... some of this "why do we want this" would belong in the commit message
imo, not just here.
Jan
next prev parent reply other threads:[~2021-04-27 6:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 17:25 [RFC PATCH] iommu: make no-quarantine mean no-quarantine Scott Davis
2021-04-27 6:56 ` Jan Beulich [this message]
2021-04-27 22:00 ` Scott Davis
2021-04-28 6:15 ` Jan Beulich
2021-04-28 7:19 ` Paul Durrant
2021-04-28 8:49 ` Jan Beulich
2021-04-28 8:51 ` Paul Durrant
2021-04-29 21:04 ` Scott Davis
2021-04-30 7:15 ` Jan Beulich
2021-04-30 19:27 ` Scott Davis
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=cea1d2d0-fd69-a4cd-6653-dd881d07b96a@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=scott.davis@starlab.io \
--cc=scottwd@gmail.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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).