On 24/12/24 22:27, David Hildenbrand wrote:
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
thanks for confirming. I saw that but could not spot the in-place
conversion there. And I had to re-watch how pKVM actually works :)
--
Alexey
