Currently we don't allow passing through any group devices which are
sharing same RMRR entry since it would break security among VMs. And
indeed, we expect we can figure out a better way to handle this kind
of case completely.
But before the group assignment gets implemented, we might make this
permission dependent on our RMRR policy. So, now it would be allowed
in the relaxed mode.
CC: Yang Zhang <yang.z.zh...@intel.com>
CC: Kevin Tian <kevin.t...@intel.com>
CC: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Tiejun Chen <tiejun.c...@intel.com>
---
xen/drivers/passthrough/vtd/iommu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 836aed5..4249cfa 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2310,12 +2310,16 @@ static int intel_iommu_assign_device(
PCI_DEVFN2(bdf) == devfn &&
rmrr->scope.devices_cnt > 1 )
{
+ u32 relaxed = flag & XEN_DOMCTL_DEV_RDM_RELAXED;
+
printk(XENLOG_G_ERR VTDPREFIX
- " cannot assign %04x:%02x:%02x.%u"
+ " Currently its %s to assign %04x:%02x:%02x.%u"
" with shared RMRR at %"PRIx64" for Dom%d.\n",
+ relaxed ? "risky" : "disallowed",
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
rmrr->base_address, d->domain_id);
- return -EPERM;
+ if ( !relaxed )
+ return -EPERM;
}
}
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
