On 24.12.24 05:21, Alexey Kardashevskiy wrote:
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.
I remember that so far only Kernel patches are available [1], I assume
because Google focuses on other user space than QEMU. So I suspect the
QEMU integration is still TBD.
[1] https://lkml.kernel.org/r/20241213164811.2006197-1-tabba@xxxxxxxxxx
--
Cheers,
David / dhildenb
