From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr Date: Fri, 04 Sep 2015 02:17:52 -0600 Message-ID: <55E96FD0020000780009F86A@prv-mh.provo.novell.com> References: <1437579859-24485-1-git-send-email-ian.jackson@eu.citrix.com> <1437579859-24485-16-git-send-email-ian.jackson@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel , Tiejun Chen Cc: Kevin Tian , xen-devel@lists.xensource.com, Wei Liu , Ian Campbell , George Dunlap , Ian Jackson , Yang Zhang List-Id: xen-devel@lists.xenproject.org >>> On 03.09.15 at 21:39, wrote: > So this change in 4.6 prevents me from passing through devices that have > worked previously with VT-d: > > (XEN) [VT-D] cannot assign 0000:00:1a.0 with shared RMRR at ae8a9000 for > Dom30. > (XEN) [VT-D] cannot assign 0000:00:1d.0 with shared RMRR at ae8a9000 for > Dom31. > > The devices are the USB 2.0 devices on a DQ67SW motherboard: > > 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #2 (rev 04) > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #1 (rev 04) Please don't top post. And I'm also puzzled by you sending this to Ian rather than the author. Technically - Tiejun, should this perhaps be permitted in relaxed mode, at least until group assignment gets implemented? (Or Tamas, do you actually mean to assign these to _different_ guests, considering the log fragment above?) Jan > On Wed, Jul 22, 2015 at 9:44 AM, Ian Jackson > wrote: > >> From: Tiejun Chen >> >> Currently we're intending to cover this kind of devices >> with shared RMRR simply since the case of shared RMRR is >> a rare case according to our previous experiences. But >> late we can group these devices which shared rmrr, and >> then allow all devices within a group to be assigned to >> same domain. >> >> CC: Yang Zhang >> CC: Kevin Tian >> Signed-off-by: Tiejun Chen >> Acked-by: Kevin Tian >> --- >> xen/drivers/passthrough/vtd/iommu.c | 30 +++++++++++++++++++++++++++--- >> 1 file changed, 27 insertions(+), 3 deletions(-) >> >> diff --git a/xen/drivers/passthrough/vtd/iommu.c >> b/xen/drivers/passthrough/vtd/iommu.c >> index 8a8d763..ce5c295 100644 >> --- a/xen/drivers/passthrough/vtd/iommu.c >> +++ b/xen/drivers/passthrough/vtd/iommu.c >> @@ -2293,13 +2293,37 @@ static int intel_iommu_assign_device( >> if ( list_empty(&acpi_drhd_units) ) >> return -ENODEV; >> >> + seg = pdev->seg; >> + bus = pdev->bus; >> + /* >> + * In rare cases one given rmrr is shared by multiple devices but >> + * obviously this would put the security of a system at risk. So >> + * we should prevent from this sort of device assignment. >> + * >> + * TODO: in the future we can introduce group device assignment >> + * interface to make sure devices sharing RMRR are assigned to the >> + * same domain together. >> + */ >> + for_each_rmrr_device( rmrr, bdf, i ) >> + { >> + if ( rmrr->segment == seg && >> + PCI_BUS(bdf) == bus && >> + PCI_DEVFN2(bdf) == devfn && >> + rmrr->scope.devices_cnt > 1 ) >> + { >> + printk(XENLOG_G_ERR VTDPREFIX >> + " cannot assign %04x:%02x:%02x.%u" >> + " with shared RMRR at %"PRIx64" for Dom%d.\n", >> + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), >> + rmrr->base_address, d->domain_id); >> + return -EPERM; >> + } >> + } >> + >> ret = reassign_device_ownership(hardware_domain, d, devfn, pdev); >> if ( ret ) >> return ret; >> >> - seg = pdev->seg; >> - bus = pdev->bus; >> - >> /* Setup rmrr identity mapping */ >> for_each_rmrr_device( rmrr, bdf, i ) >> { >> -- >> 1.7.10.4 >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >>