| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: Resend: RE: enable_ats_device() call site
>>> On 20.10.11 at 00:20, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
>> I reckon that the availability of device specifications in the ATSR data
> structure must be there for a purpose.
>> If that's not correct, then I'll certainly remove that code again, but I'd
> like to understand what that data is meant
>> to be for in that case.
>
> The atsr leverages the same PCI device scope is used for drhd and rmrr so
> device and function comes along with bus number. As far as I can tell, we
> only need to check the bus number for atsr.
So why does the capability to list individual devices then exist? And
why does it matter for DRHDs, but not for ATSRs?
>> Either we don't need to call it at all during discovery (which I doubt,
> since when the device is in use by Dom0, I
>> suppose having ATS enabled is still desirable or even required), or we have
> to potentially do it twice (remember
>> that older Dom0 kernels may fail to report all PCI devices to the
> hypervisor).
>
> I see, calling enable_ats_device() in pci_add_device() will also solve the
> case where MMCFG might not work until after dom0 is initialized.
>
> As I mentioned before, our QA team doesn't test ATS and ACS regularly. It
> would good if you can coordinate with our QA team to test out these changes
> to make sure they don't break any ACS and ATS functionality.
How would I do that other than by getting the stuff committed and
wait for their bi-weekly(?) testing round?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home