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

["Jan Beulich" <JBeulich@xxxxxxxx>]

Ping?

>>> On 23.08.11 at 10:27, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> 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 




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