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

[Alexey Kardashevskiy <aik@amd.com>]

On 14/11/24 13:27, Chao Gao wrote:
>>> 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.


Have you found out if there are patches, somewhere? I am interested too. 
Thanks,
-- 
Alexey