Re: [PATCH v2] intel_iommu: Allow both Status Write and Interrupt Flag in QI wait

[CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>]

On 15/07/2025 10:27 am, David Woodhouse wrote:
> On Tue, 2025-07-15 at 06:11 +0000, CLEMENT MATHIEU--DRIF wrote:
>>
>>
>> On 14/07/2025 11:22 pm, Konstantin Belousov wrote:
>>> Caution: External email. Do not open attachments or click links,
>>> unless this email comes from a known sender and you know the
>>> content is safe.
>>>
>>>
>>> On Mon, Jul 14, 2025 at 05:41:22PM +0100, David Woodhouse wrote:
>>>> On 14 July 2025 15:28:09 GMT+01:00, Yi Liu <yi.l.liu@intel.com>
>>>> wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2025/7/14 16:00, David Woodhouse wrote:
>>>>>> From: David Woodhouse <dwmw@amazon.co.uk>
>>>>>>
>>>>>> FreeBSD does both, and this appears to be perfectly valid. The VT-d
>>>>>> spec even talks about the ordering (the status write should be done
>>>>>> first, unsurprisingly).
>>
>> Are you talking about the ordering constraint mentioned in bullet
>> "Page-request Drain (PD)"?
>>
> 
> No, in the v4.0 spec it's just below that bullet list, at the bottom of
> §6.5.2.8.
> 
> The wording in §6.5.2.9 is even clearer:
> 
> "The invalidation completion event interrupt must push any in-flight
> invalidation completion status writes, including status writes that may
> have originated from the same inv_wait_dsc for which the interrupt was
> generated."

Fine

> 
>>>>> I think this "if branch" can be moved just after the inv_desc non-zero
>>>>> reserved bit checking. Hence you don't need a ret at all. :)
>>>>
>>>> We want to return false if the memory write fails, and the
>>>> interrupt has to happen afterwards.
>>
>> Per spec: "Hardware behavior is undefined if the Status Address
>> specified is not an address route-able to memory"
>>
>> Do we want to trigger the interrupt even when the DMA fails?
> 
> Yes, we do. That's a quality of implementation issue. Just because the
> behaviour is 'undefined' and theoretically gives us permission to do
> whatever we like to the guest, we should still be as sensible as
> possible.

lgtm

> 
> 
>>>>
>>>>> btw. I'm
>>>>> also asking if VT-d spec allows it or not. So let's wait for a
>>>>> while..
> 
> Rapidly losing interest in this conversation. QEMU currently has a
> guest-triggerable crash, for crying out loud. I'd like to fix it and
> move on to finding out why FreeBSD doesn't work *even* when QEMU
> doesn't abort...