[Xen-devel] RE: Resend: RE: enable_ats_device() call site

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 23.08.11 at 00:01, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
>> And why is it VT-d specific then? The problem to solve is that enabling
>>may not happen when it is first attempted, in the case where Xen on its
>>own can't be certain that using MMCFG is safe. Hence when the device
>>gets reported by Dom0 (or when MMCFG gets enabled for the respective
>>bus), another attempt needs to be made at enabling it. De-assigning and
>>then re-assigning the device to Dom0 seems to be overkill to me.
> 
> The part that is VT-d specific is ATS capability reporting in ACPI DMAR
> table for reporting ATS capability in root ports.  I not so clear on what
> do you mean by making another attempt when initial ATS enabling attempt 
> fails.

The initial enabling may fail because of the unavailability of MMCFG
accesses (due to the memory range(s) used not being reserved in E820,
which is not required to be the case by the spec). Once MMCFG gets
enabled, this needs to be re-attempted at some point, and the logical
point appears to be when the device gets re-registered by Dom0.

> Do you have a patch to address this issue?

Only for the (trivial) ACS part so far (see below).

There's also a second aspect here: the bus-to-bridge mappings
currently get established just once, during boot. This is already
hot(un)plug incompatible, but will become even more of a problem
when multi-segment support gets in (I should be sending out patches
soon), for the same MMCFG-initially-unavailable reason as outlined
above (as in that case non-zero segments can't be scanned at boot).

Jan

--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -350,9 +350,10 @@ int pci_add_device(u16 seg, u8 bus, u8 d
         }
 
         list_add(&pdev->domain_list, &dom0->arch.pdev_list);
-        pci_enable_acs(pdev);
     }
 
+    pci_enable_acs(pdev);
+
 out:
     spin_unlock(&pcidevs_lock);
     printk(XENLOG_DEBUG "PCI add %s %04x:%02x:%02x.%u\n", pdev_type,



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel