Re: [Xen-devel] ATS and dependent features

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

> -----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. 
Xiantao 


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