[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |