On Tue, Nov 12, 2024 at 01:30:06PM +0100, David Hildenbrand wrote: >Hi, > >the next guest_memfd upstream call will happen this Thursday, 2024-11-14 >at at 9:00 - 10:00am (GMT-08:00) Pacific Time - Vancouver. > >We'll be using the following Google meet: >http://meet.google.com/wxp-wtju-jzw > >The meeting notes are linked from the google calendar invitation. If you >want an invitation that also covers all future meetings, just write me a >mail. > >In this meeting we'll discuss: >* fbind() and NUMA mempolicy for guest_memfd >* Persisting guest_memfd across reboot / guest_memfs >* guest_memfd use cases for a PFN range allocator > >And we'll continue our discussion on: >* Challenges with supporting huge pages >* Challenges with shared vs. private conversion >* guest_memfd as a "library" > >To put something to discuss onto the agenda, reply to this mail or add >them to the "Topics/questions for next meeting(s)" section in the >meeting notes as a comment. Hi David, We would like to discuss how to adapt the proposal for shared device assignment [1] to recent guest_memfd changes, such as the support of in-place conversion. With in-place conversion, QEMU can map shared memory and supply the virtual address to VFIO to set up DMA mappings. From this perspective, in-place conversion doesn't change or require any changes to the way QEMU interacts with VFIO. So, the key for device assignment remains updating DMA mappings accordingly during shared/private conversions. It seems that whether in-place conversion is in use (i.e., whether shared memory is managed by guest_memfd or not) doesn't require big changes to that proposal. Not sure if anyone thinks otherwise. We want to align with you on the direction for device assignment support for guest_memfd. (I set aside the idea of letting KVM manage the IOMMU page table in the above analysis because we probably won't get that support in the near future) Could you please add this topic to the agenda? btw, the current time slot is not very convenient for us. If possible, could we schedule the meeting one hour earlier, if this works for others? Two hours earlier would be even better [1]: https://lore.kernel.org/all/20240725072118.358923-1-chenyi.qiang@xxxxxxxxx/
