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

> >> >   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.
> 
> Why? That would e.g. make lspci completely unreliable.

yes,  if these capabilities are completely virtualized, lspci should be  break. 
Xiantao 


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