On 5/14/25 5:32 AM, Thomas Huth wrote: > On 13/05/2025 15.42, Matthew Rosato wrote: >> On 5/13/25 2:50 AM, Christian Borntraeger wrote: >>> Am 29.04.25 um 16:09 schrieb Matthew Rosato: >>>> On 4/29/25 3:45 AM, Christian Borntraeger wrote: >>>>> Am 29.04.25 um 09:37 schrieb David Hildenbrand: >>>>> [...] >>>>>> The only problem I see is with vfio devices is the new "memory pinned" >>>>>> mode. [1] >>>>>> >>>>>> There, we'd have to check if any such device is around (discarding of >>>>>> ram is disabled?), and fallback to actual zeroing of memory. >>>>> >>>>> CC Matt to double check. >>>> >>>> When triggering the "relaxed translation" mode via iommu.passthrough in >>>> the guest, we now take the default (for other platforms) >>>> memory_region_is_ram() path in vfio_listener_region_add/del() which >>>> handles the pin/unpin from vfio common code. As for ram discarding, we >>>> then also use the vfio common path and only uncoordinated discards are >>>> disabled via: >>>> >>>> vfio_ram_block_discard_disable() -> >>>> ram_block_uncoordinated_discard_disable() >>> >>> So this patch is good? >>> >> >> Worked fine in my testing in combination with iommu.passthrough=1. I traced >> to verify I was hitting the S390_RESET_REIPL_CLEAR path in >> s390_machine_reset() and observed the pinned memory of the guest shrink / >> grow. Device worked fine afterwards. > > What about David's concern here: > https://lore.kernel.org/qemu-devel/489d0473-579a-4850-a6d5-be38bf295...@redhat.com/ > ? >
With the current code + this patch applied and testing with a vfio-pci device in the pinned mode, I can observe the pinned memory be discarded / pinned memory shrinks until finally ram_discard_block_range returns rc=0. We don't disable discarding of ram when using the vfio-pci pinned memory mode, we only disable uncoordinated discarding of ram - maybe David's concern was based on an older version of my implementation that required disabling both coordinated and uncoordinated discards? Or am I missing some other concern?
