On 13.11.24 07:06, Chao Gao wrote:
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,
Hi!
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.
Makes sense.
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)
Right. So devices would also only be to access "shared" memory.
Could you please add this topic to the agenda?
Will do. But I'm afraid the agenda for tomorrow is pretty packed, so we
might not get to talk about it in more detail before the meeting in 2 weeks.
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
Time zones and daylight saving are confusing, so I'm relying on Google
calender; it says that the meeting is going to be at 9am pacific time,
which ends up being 6pm German time. I suspect that's 1am in China? :( I
know that Gavin from Australia is also not able to join unfortunately
... something like 4am for him.
We can discuss tomorrow if we could move it to 8am pacific time (which I
would welcome as well :) ) for the next meeting. 7am pacific time is
likely a bit of a stretch though.
--
Cheers,
David / dhildenb
