Re: [Xen-devel] ATS and dependent features

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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