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

Re: [Xen-devel] [PATCH, RFC 0/7] IOMMU: add phantom function support


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Fri, 30 Nov 2012 00:37:48 +0000
  • Accept-language: en-US
  • Cc: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 30 Nov 2012 00:38:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHNzgZ7ISPR/wCD+k2jHDaUEkQbqJgBiMvA
  • Thread-topic: [Xen-devel] [PATCH, RFC 0/7] IOMMU: add phantom function support


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, November 29, 2012 3:53 PM
> To: Zhang, Xiantao
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH, RFC 0/7] IOMMU: add phantom function
> support
> 
> >>> On 28.11.12 at 10:41, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > While I'm unaware of devices making use of this functionality in
> > proper ways, the goal of this patch set is to leverage the enabling of
> > the specified behavior as a workaround for devices that behave as if
> > they made use of this functionality _without_ advertising so in the
> > PCIe capability structure.
> >
> > While it would have been possible to leave the generic IOMMU code
> > untouched, and deal with the creation of the necessary device context
> > entries in the individual IOMMUs' implementations, I felt that it was
> > cleaner to have as much of the necessary abstraction in the generic
> > layer.
> >
> > The adjustments in particular imply that for the relevant operations,
> > (PCI-dev, devfn) tuples get passed, with the PCI device referring to
> > the real device and devfn representing either the real device or the
> > phantom function. Consequently, for any operation intended to deal
> > with the real device, the devfn of the device itself must be used,
> > whereas for anything targeting the phantom function the passed in
> > value is the correct one to pass on.
> >
> > 1: IOMMU: adjust (re)assign operation parameters
> > 2: IOMMU: adjust add/remove operation parameters
> > 3: VT-d: adjust context map/unmap parameters
> > 4: AMD IOMMU: adjust flush function parameters
> > 5: IOMMU: consolidate pdev_type() and cache its result for a given
> > device
> > 6: IOMMU: add phantom function support
> > 7: IOMMU: add option to specify devices behaving like ones using
> > phantom functions
> >
> > As the patch set wasn't tested on the affected systems yet, I'm
> > intentionally not adding S-o-b tags yet. I would appreciate review
> > nevertheless (and even more so, given that I won't be able to test
> > this code other than what I did in contrived scenarios).
> 
> One open question (that I realized only after sending the batch) is whether
> for such devices the source ID verification should be set up using one of the
> SQ_13_IGNORE_* (fitting the stride).

Yes,  I think so.  If SVT is set to 01b,  SQ should be specially handled 
according to phantom device's  enabled functions. 
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®.