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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

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

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


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

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]