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: >>> 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."
Fine > >>>>> 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. lgtm > > >>>> >>>>> 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...
