Re: [Xen-devel] iommu=dom0-passthrough behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.11.12 at 01:11, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2012-11-05:
>> so far it was my understanding that this option is intended to get
>> the DMA behavior that Dom0 observes as close as possible to how
>> it would be without IOMMU.
> 
> Correct. There is a bit in context entry which controlling the DMA 
> request(from this device) to walk or not walk the iommu page table.
> As we known, walking page table introduced extra cost, so we use this 
> parameter to make sure the device which owned by dom0 not to walking iommu 
> page table when DMA request is arrived.

Okay, so that would be slightly different from the meaning I give
to the option (as described above).

>> However, we're now dealing with a customer report where a
>> single function device is observed to initiate DMA operations
>> appearing to originate from function 1, which makes obvious that
>> the option above is not making things as transparent as I would
>> have expected them to be: Without IOMMU, such requests get
>> processed fine, while with IOMMU (due to there not being a
>> context entry for the bogus device) the device fails to initialize
>> (causing DMA faults, the presence of which I had to convince
>> myself of separately, as for whatever reason at least the VT-d
>> code doesn't issue any log message in that case).
> 
> Sorry, I cannot understand your problem. Is there any bug in current VT-d 
> code?

We need to settle on the concept here first: What specifically is
said option intended to do?

Only then we can talk about bugs, and if there is one I suspect it's
not only in VT-d code, but equally much in AMD IOMMU's.

The thing here is that a device functioning properly without IOMMU
(with "properly" not necessarily meaning it being implemented
correctly as per specification, albeit I also didn't check whether the
spec would allow for the observed behavior) doesn't once DMA
translation is enabled (even if suppressed for Dom0 via above
option).

The problem being that while device enumeration only finds a single
device at function zero of the respective (seg,bus,dev) tuple, DMA
requests - as seen by the IOMMU - originate from non-zero
functions under the same tuple. Since a non-discovered device
doesn't get a context entry inserted, this result in an IOMMU fault,
rendering the device non-functional.

The data from the system I have so far doesn't tell me whether the
device incorrectly claims itself as single function (with the functions
other than func 0 simply not being discovered during device
enumeration, as single function devices don't get their non-zero
functions scanned) or whether the config space for functions 1-7
indeed is unpopulated, with the device issuing requests with non-
zero function number for other, unexplained reasons.

Bottom line - I'm seeking advice as to whether working around
this problem in the IOMMU code is desirable/necessary, or
whether this is a design flaw on the device's side that just
cannot be tolerated with an IOMMU in the picture (which would
need good reasoning, so that a customer expecting such a
device to work regardless of IOMMU usage can understand that
this cannot reasonably be made work).

Jan


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