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
