| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: enable_ats_device() call site
> what is the reason for calling this from VT-d's domain_context_mapping()?
> I neither undertsand why this is VT-d specific, nor why it needs to be
> re-done with each device re-assignment.
The reason is FLR clears the ATS enabled bit so we need to re-enable it for
every re-assignment. The reason we don't need to do this for ACS might be ACS
reside on the bridge, not in the PCI endpoint. ATS on the other hand, resides
in PCI endpoints.
> Alternatively - why do we need scan_pci_devices() at all? We're
> supposed to be getting the devices reported from Dom0 anyway
Looks like it is use for building bus2bridge[] which is used for figuring out
upstream bridges which are needed when assigning non-PCIe devices.
Allen
-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
Sent: Monday, August 15, 2011 9:25 AM
To: Kay, Allen M
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: enable_ats_device() call site
Allen,
what is the reason for calling this from VT-d's domain_context_mapping()?
I neither undertsand why this is VT-d specific, nor why it needs to be
re-done with each device re-assignment.
I'm asking because this depends on MMCFG availability, and hence the
initial call from pci_add_device() (in the context of scan_pci_devices())
to iommu_add_device() may not result in this getting enabled, while on
the first Dom0-invoked pci_add_device() pdev->domain is already set
and hence iommu_add_device() doesn't get called at all. I'd therefore
like to pull this out into pci_add_device() (and call it, together with
pci_enable_acs(), after the conditional around iommu_add_device() -
should be safe as I view both enabling functions as idempotent).
Alternatively - why do we need scan_pci_devices() at all? We're
supposed to be getting the devices reported from Dom0 anyway.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home