Re: [Xen-devel] ATS and dependent features

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

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

> >   Perhaps we need to forbid dom0 controlling these features.
> 
> That's what I was trying to find out. How to properly do that with pv-ops I
> don't know; in our forward ported kernels I can simply make the respective
> config options conditional upon !XEN. 

As to the clean solution, Xen should intercept all the accesses to the device's 
PCI config space from dom0, and emulates the related registers.  In your simple 
solution, it maybe break the kernel running with these features on native 
hardware.  If adopts pv_ops method to solve such corner issues, it may be not 
acceptable by upstream kernel.   
Xiantao  

> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] while investigating an
> >> issue with some device not working under Xen without "ats=off", I
> >> started wondering whether it is correct to allow the Dom0
> > kernel
> >> concurrent control over ATS, PRI, and PASID - it would seem to me
> >> that with Xen controlling the IOMMU, it should also have exclusive
> >> control over the enabling of those features.
> >>
> >> Thanks for any comments in this regard, Jan
> 
> 


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