> -----Original Message----- > From: Zhangfei Gao <[email protected]> > Sent: 14 November 2025 08:45 > To: Nicolin Chen <[email protected]> > Cc: Shameer Kolothum <[email protected]>; qemu- > [email protected]; [email protected]; [email protected]; > [email protected]; Nathan Chen <[email protected]>; Matt Ochs > <[email protected]>; [email protected]; > [email protected]; Jason Gunthorpe <[email protected]>; > Krishnakant Jaju <[email protected]> > Subject: Re: [RFC PATCH 4/4] hw/arm/smmuv3-accel: Read and propagate > host vIOMMU events > > External email: Use caution opening links or attachments > > > On Fri, 14 Nov 2025 at 01:44, Nicolin Chen <[email protected]> wrote: > > > > On Thu, Nov 13, 2025 at 05:07:50AM -0800, Shameer Kolothum wrote: > > > > On Wed, 5 Nov 2025 at 23:49, Shameer Kolothum > > > > <[email protected]> wrote: > > > > > > > > > > Install an event handler on the vEVENTQ fd to read and propagate host > > > > > generated vIOMMU events to the guest. > > > > > > > > > > The handler runs in QEMU’s main loop, using a non-blocking fd > registered > > > > > via qemu_set_fd_handler(). > > > > > > > > > > Signed-off-by: Shameer Kolothum <[email protected]> > > > > > > > > Still don't understand how to use this vevent. > > > > Is it to replace the fault queue (IOMMU_FAULT_QUEUE_ALLOC)? > > > > > > No. IIUC, IOMMU_FAULT_QUEUE_ALLOC is to handle I/O page faults > > > for any HWPT capable of handling page faults/response. The QEMU > > > SMMUv3 still don't support page fault handling. > > > > > > The VEVENTQ, on the other hand, provides a way to report any > > > other s1 events to Guest. > > > > > > See how events are reported in arm_smmu_handle_event(): > > > > > > if (event->stall) > > > ret = iommu_report_device_fault(master->dev, &fault_evt); //Page > > > faults > > > else if (master->vmaster && !event->s2) > > > ret = arm_vmaster_report_event(master->vmaster, evt); //This series > handles this case. > > > else > > > ret = -EOPNOTSUPP; > > > > Yes. We can say that FAULT_QUEUE is exclusively for PRI while the > > vEVENTQ is for other types of HW events (or IRQs) related to the > > guest stage-1. They can be used together. > > > > > > And only find read, no write, only receive events but no response > > > > (from guest kernel)? > > > > > > Yes. And I am not sure what the long term plan is. We can still use > > > IOMMU_FAULT_QUEUE_ALLOC for page fault handling or extend this > > > VEVENTQ to have write() support for responses > > > > > > To me, from an implementation perspective, both this FAULT and > > > VEVENTQ look almost similar. > > > > > > @Nicolin, any idea what's plan for page fault handling? > > > > No. I think PRI should be done via FAULT_QUEUE. > > Does that mean FAULT_QUEUE needs a response, so read + write > VEVENTQ only notify, no need response, only read.
Of course. Page fault needs a response always whether abort or retry. VEVENTQ is for everything excepts page fault event that doesn't need any response back. If you are after the STALL based page fault handling on D06, you could rebase the old page fault/response patches on top of this and handle it, I guess. Thanks, Shameer
