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/
?
Thomas
