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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.11.12 at 01:37, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:

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

I suppose, in a similar fashion, amd_iommu_msi_msg_update_ire()
would need to call update_intremap_entry_from_msi_msg() more
than once for dealing with phantom functions?

If so, in order to make clear that, other than for VT-d, the MSI
message doesn't get altered, I would want to constify that
parameter of update_intremap_entry_from_msi_msg() as I go.

Jan


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