WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: [Xen-devel] RE: Resend: RE: enable_ats_device() call site
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Thu, 20 Oct 2011 18:59:14 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Li, Susie" <susie.li@xxxxxxxxx>
Delivery-date: Thu, 20 Oct 2011 19:00:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E9FE8B6020000780005C661@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E4E48360200007800051F65@xxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301EE709B5E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E8EC8A80200007800059E3B@xxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301EE70A446@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E9458A5020000780005AB99@xxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301F19DB855@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E9E8EA1020000780005C155@xxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301F1D86476@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E9FE8B6020000780005C661@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyO+UQ4oIO1WijkSpOb95UD0yQgfQAmOcvQ
Thread-topic: Resend: RE: enable_ats_device() call site
> 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