Re: [Xen-devel] ATS and dependent features

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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