On 2025/7/16 12:05, Konstantin Belousov wrote:
On Wed, Jul 16, 2025 at 12:01:44PM +0800, Yi Liu wrote:
On 2025/7/15 20:27, CLEMENT MATHIEU--DRIF wrote:
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:
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....@intel.com>
wrote:
Hi David,
On 2025/7/14 16:00, David Woodhouse wrote:
From: David Woodhouse <d...@amazon.co.uk>
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.
Personally, I'm fine with generating the interrupt even the status write
failed. But to avoid potential conflict, I've also raised this question to
the VT-d spec owner. Haven't got a clear answer yet. To further understand
this, may I ask some dumb questions here. Why FreeBSD set both SW and IF
flag. What is the usage model here. Would software consider that all the QI
descriptors prior to this specific wait descriptor has succeeded when
either the interrupt got invoked or the expected status is written back?
FreeBSD queues invalidations, each invalidation has the gen number. To
know that some invalidation finished, FreeBSD waits for the interrupt,
we do not scan the invalidation sequence word otherwise. There might be
further generations of the invalidation descriptors in flight when we
get the interrupt, which means that we need to know which generation is
finished.
thanks for the explanation. So software still relies on checking the
written back status of the wait descriptor to identify finished
invalidation. If so might be better to generate interrupt when status write
is succeeded? Otherwise, the interrupt is meaningless to software. Does the
current software implementation rely on this interrupt even status write
failed?
Regards,
Yi Liu
