> From: Alexey Kardashevskiy <aik@xxxxxxx> > Sent: Thursday, August 29, 2024 10:14 PM > > On 29/8/24 06:43, Dan Williams wrote: > > Alexey Kardashevskiy wrote: > >> Assumptions > >> ----------- > >> > >> This requires hotpligging into the VM vs > >> passing the device via the command line as > >> VFIO maps all guest memory as the device init > >> step which is too soon as > >> SNP LAUNCH UPDATE happens later and will fail > >> if VFIO maps private memory before that. > > > > Would the device not just launch in "shared" mode until it is later > > converted to private? I am missing the detail of why passing the device > > on the command line requires that private memory be mapped early. > > A sequencing problem. > > QEMU "realizes" a VFIO device, it creates an iommufd instance which > creates a domain and writes to a DTE (a IOMMU descriptor for PCI BDFn). > And DTE is not updated after than. For secure stuff, DTE needs to be > slightly different. So right then I tell IOMMUFD that it will handle > private memory. > > Then, the same VFIO "realize" handler maps the guest memory in iommufd. > I use the same flag (well, pointer to kvm) in the iommufd pinning code, > private memory is pinned and mapped (and related page state change > happens as the guest memory is made guest-owned in RMP). > > QEMU goes to machine_reset() and calls "SNP LAUNCH UPDATE" (the actual > place changed recenly, huh) and the latter will measure the guest and > try making all guest memory private but it already happened => error. > > I think I have to decouple the pinning and the IOMMU/DTE setting. > Assume there will be a new hwpt type which hints for special DTE setting at attach time and connects to a guest memfd. It'd make sense to defer mapping guest memory to a point after "SNP LAUNCH UPDATE" is completed for devices attached to such hwpt, as long as we document such restriction clearly for that new type. 😊
