Re: [PATCH] vfio/listener: Only warn on misalignment for VFIO-owned regions

[Alex Williamson <alex@shazbot.org>]

On Mon, 6 Jul 2026 17:12:35 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Mon, 6 Jul 2026 at 16:42, Alex Williamson <alex@shazbot.org> wrote:
> >
> > On Mon, 6 Jul 2026 16:27:46 +0100
> > Peter Maydell <peter.maydell@linaro.org> wrote:  
> > > It seems very unlikely that anything not page-aligned is going
> > > to be a sensible target for DMA ops from a device: the main
> > > reason to have a non-page-aligned or non-page-sized region is that
> > > it's the way we've chosen to implement a device, or it's some
> > > "RAM but not general-purpose RAM" thing. If there's a path to
> > > warn/error if it's actually used for a DMA op that would be worthwhile,  
> >
> > But for a vfio-pci device there is no DMA op, it either gets mapped
> > into the IOMMU for direct access to the device or not.  This is the
> > point at which that decision is made.  
> 
> Why is small RAM different from MMIO register regions here?
> Those also you're not going to be able to have a device do
> direct memory access to.

There's a precedent for bare metal, peer-to-peer DMA is less reliable
and drivers don't typically have blind faith in it working.
Peer-to-peer DMA also has specific use cases, drivers don't arbitrarily
pick a peer device to DMA to, they have specific use cases and target
regions are inherently sized and aligned appropriately.

Here we have RAM and we're trying to determine whether it's RAM that
could be allocated as a DMA buffer or expect a DMA access from a
device.

Commit 851d6d1a0ff2 spelled out that we could have declared these sorts
of regions as RAM device, solving the problem with a simple test, but
that wasn't well received (for reasons I don't remember), so we were
forced to create this mechanism and maintenance issue.

> > > but as it stands I think all this warning will ever cause us to
> > > do is add more entries to its whitelist every time it complains.  
> >
> > IMO, that's ok.  That's the purpose.  We're up to one whole class of
> > device so far, we don't care about mapping failures to TPM devices.  If
> > some day this does fire on something we care about, especially a
> > regression, it'll earn its keep.  It doesn't seem like an excessive
> > burden yet. Thanks,  
> 
> The reason we're having this conversation is because it just fired
> again, and the warning gives the impression that the right thing
> to do is to somehow change the misaligned memory region, not to
> add something to the whitelist. That's already wasted several
> people's time.

Since being introduced 4 years ago, we've iterated on one class of
device.  It doesn't feel like there's a persistent time sink here.

> You could add a comment saying
> 
> /*
>  * If this warning ever fires, then it will almost certainly
>  * be because of a legitimately non-aligned RAM-backed
>  * MemoryRegion that needs adding to the whitelist.
>  */

Personally I'd start with the error log itself, providing a hint that
the region is presented as RAM but isn't sized/aligned for DMA from a
vfio device, with a hint to mark it as safe if it is legitimately not a
valid DMA target.  Thanks,

Alex