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

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

Jan,

Thanks for the reminder.  This has slip through the cracks.  The patch look 
good.  With this patch, we shouldn't need the existing call to pci_enable_acs() 
in setup_dom0_devices(), correct?

I agree that the same problem exists for bus-to-bridge mapping function 
pci_scan_device().  By the way, we probably should take the opportunity to give 
it a proper name that reflects to the true purpose of this function.

Allen

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Tuesday, September 20, 2011 6:57 AM
To: Kay, Allen M
Cc: Xen Devel
Subject: [Xen-devel] RE: Resend: RE: enable_ats_device() call site

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