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