On Wed, Jul 16, 2025 at 05:23:57PM +0800, Yi Liu wrote: > 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?
Yes, if the inv sequence word is not updated past the requested value, the interrupt is basically ignored. OTOH, the FreeBSD DMAR driver (should) never program non-main memory physical address into the address field of the inv descriptor. And we use the same location for all invalidations issued from the single DMAR unit.
