Re: [Xen-devel] ATS and dependent features

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.12.12 at 16:13, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> On Tue, Dec 04, 2012 at 08:12:25AM +0000, Jan Beulich wrote:
>> >>> On 04.12.12 at 02:29, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
>> 
>> > 
>> >> -----Original Message-----
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Monday, December 03, 2012 3:55 PM
>> >> To: Zhang, Xiantao
>> >> Cc: xen-devel
>> >> Subject: RE: ATS and dependent features
>> >> 
>> >> >>> On 30.11.12 at 13:29, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
>> >> wrote:
>> >> 
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> >> Sent: Thursday, November 29, 2012 5:28 PM
>> >> >> To: Zhang, Xiantao
>> >> >> Cc: xen-devel
>> >> >> Subject: RE: ATS and dependent features
>> >> >>
>> >> >> >>> On 29.11.12 at 10:19, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
>> >> >> wrote:
>> >> >>
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> >> >> Sent: Thursday, November 29, 2012 4:01 PM
>> >> >> >> To: Zhang, Xiantao
>> >> >> >> Cc: xen-devel
>> >> >> >> Subject: RE: ATS and dependent features
>> >> >> >>
>> >> >> >> >>> On 29.11.12 at 02:07, "Zhang, Xiantao"
>> >> >> >> >>> <xiantao.zhang@xxxxxxxxx>
>> >> >> >> wrote:
>> >> >> >> > ATS should be a host feature controlled by iommu, and I don't
>> >> >> >> > think
>> >> >> >> > dom0 can control  it from Xen's architecture.
>> >> >> >>
>> >> >> >> "Can" or "should"? Because from all I can tell it currently clearly 
>> >> >> >> does.
>> >> >> >
>> >> >> > I mean Xen shouldn't  allow these capabilities can be detected by
>> >> >> > dom0.  If it does, we need to fix it.
>> >> >>
>> >> >> It sort of hides it - all callers sit in the kernel's IOMMU code, and
>> >> >> IOMMU detection is being prevented. So it looks like the code is
>> >> >> simply dead when running on top of Xen.
>> >> >
>> >> > I'm curious why dom0's !Xen kernel option for these features can solve
>> >> > the issue you met.
>> >> 
>> >> It doesn't "solve" the problem in that sense: As said, the code in 
>> >> question
>> >> only has callers in IOMMU code, which itself is dependent on !XEN in our
>> >> kernels (just to make clear - I'm talking about forward ported kernels 
>> >> here,
>> >> not pv-ops ones). So upstream probably just has to live with that code 
>> >> being
>> >> dead (at the moment, when run on top of Xen) and take the risk of there
>> >> appearing a caller elsewhere.
>> >> In our kernels, by making these options also dependent upon !XEN, we can
>> >> then actually detect (and actively deal with) an eventual new caller
>> >> elsewhere in the code, thus eliminating any risk of bad interaction 
>> >> between
>> >> Dom0 and Xen.
>> > 
>> > I think !Xen you are talking is a compile option, so this kernel can only 
>> > used for dom0 and can't run on native with these features enabled ?  If 
> don't 
>> > need to keep the kernel running on native hardware, I think it is fine. 
>> 
>> Yes, as said - this is for our forward ported kernel. Whether (and if
>> so how) the pv-ops one can add a similar safeguard I can't tell (and
>> doubt).
> 
> Right, in the upstream kernel that is not going to work. But I am a bit
> confused - this code (pci_enable_ats) looks to be called only from the
> intel and amd iommu code. Aren't those blacklisted (so DMAR MADT
> is overwritten and AMD PCI device is witheld) so the calls aren't going
> to be executed?

That's right. But the code being there means you wouldn't notice
(at build time) if some other caller appeared (which would need
fixing).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel