[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.