From: Nicolin Chen <redacted>
Sent: Wednesday, January 22, 2025 3:16 PM

On Tue, Jan 21, 2025 at 08:21:28PM -0400, Jason Gunthorpe wrote:

quoted

On Tue, Jan 21, 2025 at 01:40:05PM -0800, Nicolin Chen wrote:

quoted

quoted

There is also the minor detail of what happens if the hypervisor HW
queue overflows - I don't know the answer here. It is security
concerning since the VM can spam DMA errors at high rate. :|

In my view, the hypervisor queue is the vHW queue for the VM, so
it should act like a HW, which means it's up to the guest kernel
driver that handles the high rate DMA errors..

I'm mainly wondering what happens if the single physical kernel
event queue overflows because it is DOS'd by a VM and the hypervisor
cannot drain it fast enough?

I haven't looked closely but is there some kind of rate limiting or
otherwise to mitigate DOS attacks on the shared event queue from VMs?

SMMUv3 reads the event out of the physical kernel event queue,
and adds that to faultq or veventq or prints it out. So, it'd
not overflow because of DOS? And all other drivers should do
the same?

"add that to faultq or eventq" could take time or the irqthread
could be preempted for various reasons then there is always an
window within which an overflow condition could occur due to
the smmu driver incapable of fetching pending events timely.

On VT-d the driver could disable reporting non-recoverable fault
for a given device via a control bit in the PASID entry, but I didn't
see a similar knob for PRQ.

and the overflow situation on intel-iommu driver is higher than
arm. The irqthread reads head/tail once, batch-reports  the
events in-between, and then updates the head register...