Re: [Invitation] bi-weekly guest_memfd upstream call on 2024-11-14

[Chao Gao <chao.gao@intel.com>]

>> 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.

Yes, this is the situation without TDX-Connect support. Even when TDX-Connect
comes into play, devices will initially be attached in shared mode and later
converted to private mode. From this perspective, TDX-Connect will be built on
this shared device assignment proposal.

>
>> 
>> 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.

Understood. is there any QEMU patch available for in-place conversion? we would
like to play with it and also do some experiments w/ assigned devices. This
might help us identify more potential issues for discussion.

>
>> 
>> 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

Yes, this meeting starts at 1am in China.

>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.

Thanks a lot.