[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v7][PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr
>>> On 09.07.15 at 07:34, <tiejun.chen@xxxxxxxxx> wrote: > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -2297,13 +2297,39 @@ 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 ) > + { > + if ( rmrr->scope.devices_cnt > 1 ) > + { > + printk(XENLOG_G_ERR VTDPREFIX > + " cannot assign %04x:%02x:%02x.%u" > + " with shared RMRR for Dom%d.\n", > + seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), > + d->domain_id); > + return -EPERM; > + } > + } Two if()-s like these should be folded into one. In your place I'd also consider also printing the RMRR base address for easier analysis of the issue. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |