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....@intel.com> > > > wrote: > > > > Hi David, > > > > > > > > On 2025/7/14 16:00, David Woodhouse wrote: > > > > > From: David Woodhouse <d...@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...
smime.p7s
Description: S/MIME cryptographic signature
