> So why does the capability to list individual devices then exist? And why
> does it matter for DRHDs, but not for ATSRs?
The difference is ATSR only is meant to communicate PCIe root ports' ATS
capability. If the root port is capable, then downstream endpoints can enable
ATS device translation cache.
acpi_find_matched_drhd_unit() is used to find out which VT-d hardware is
servicing the endpoint device. Given drhd lists either the actually PCI
endpoints or include_all, we have to match the actual BDF of the device passed
in with devices we recorded for that VT-d HW.
acpi_find_matched_astr_unit() is used to find out if the endpoint device is
under a ATS capable PCIe root port or not. ASTR information is remembered as
secondary and subsidiary bus ranges. All we have to do is the match the
device's bus number with a root ports bus range. Matching the actual device in
this case, will only match the root port device itself, this is what we
recorded in acpi_parse_dev_scope(), which should not happen since we don't
assign a root port to a guest. Even if we do, checking for ATS capability is
meaningless since root port will not have device translation cache.
Allen
-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
Sent: Thursday, October 20, 2011 12:24 AM
To: Kay, Allen M
Cc: Dugger, Donald D; Shan, Haitao; Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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