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