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

[Konstantin Belousov via <qemu-devel@nongnu.org>]

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).
> >
> >interesting. Have you tried setting both flags on baremetal and the hw
> >gives you both the status code and an interrupt?
> 
> I see no reason why it shouldn't. The spec (§6.5.2.8) gives no that the IF and SW bits should be mutually exclusive and even talks about ordering:
> 
> Section 6.5.2.11 describes queued invalidation ordering considerations. Hardware completes an 
> invalidation wait command as follows:
> • If a status write is specified in the wait descriptor (SW=1), hardware performs a coherent write of 
> the status data to the status address.
> • If an interrupt is requested in the wait descriptor (IF=1), hardware sets the IWC field in the 
> Invalidation Completion Status Register. An invalidation completion interrupt may be generated as 
> described in the following section
> 

Yes, and the FreeBSD DMAR code uses that, and relies on that, as was
mentioned earlier in the mail thread.

> 
> 
> >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.
> 
> > btw. I'm
> >also asking if VT-d spec allows it or not. So let's wait for a while..
> 
> Ok.
> 
>