From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: ATS and dependent features Date: Tue, 4 Dec 2012 10:13:28 -0500 Message-ID: <20121204151326.GB15404@phenom.dumpdata.com> References: <50B498E502000078000AB8B3@nat28.tlf.novell.com> <50B7243602000078000AC61A@nat28.tlf.novell.com> <50B7389202000078000AC669@nat28.tlf.novell.com> <50BC68FE02000078000AD2B1@nat28.tlf.novell.com> <50BDBE7902000078000AD8E1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50BDBE7902000078000AD8E1@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xiantao Zhang , xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Dec 04, 2012 at 08:12:25AM +0000, Jan Beulich wrote: > >>> On 04.12.12 at 02:29, "Zhang, Xiantao" wrote: > > > > >> -----Original Message----- > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> 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" > >> wrote: > >> > >> > > >> >> -----Original Message----- > >> >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >> 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" > >> >> wrote: > >> >> > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >> >> 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" > >> >> >> >>> > >> >> >> 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? > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >