Re: [Xen-devel] [PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.09.15 at 21:39, <tamas.k.lengyel@xxxxxxxxx> 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 <ian.jackson@xxxxxxxxxxxxx>
> wrote:
> 
>> From: Tiejun Chen <tiejun.chen@xxxxxxxxx>
>>
>> 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 <yang.z.zhang@xxxxxxxxx>
>> CC: Kevin Tian <kevin.tian@xxxxxxxxx>
>> Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>
>> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
>> ---
>>  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@xxxxxxxxxxxxx 
>> http://lists.xen.org/xen-devel 
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel