[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] ATS and dependent features


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Fri, 30 Nov 2012 12:29:02 +0000
  • Accept-language: en-US
  • Cc: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 30 Nov 2012 12:29:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHNzINiSOuk8WhZTUOv61PMlYmAhZgAAhig///uAQCAAJGFcP//hsAAgAJJkKA=
  • Thread-topic: ATS and dependent features


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.