> From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Wednesday, June 2, 2021 6:22 AM > > On Tue, 1 Jun 2021 07:01:57 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > I summarized five opens here, about: > > > > 1) Finalizing the name to replace /dev/ioasid; > > 2) Whether one device is allowed to bind to multiple IOASID fd's; > > 3) Carry device information in invalidation/fault reporting uAPI; > > 4) What should/could be specified when allocating an IOASID; > > 5) The protocol between vfio group and kvm; > > > ... > > > > For 5), I'd expect Alex to chime in. Per my understanding looks the > > original purpose of this protocol is not about I/O address space. It's > > for KVM to know whether any device is assigned to this VM and then > > do something special (e.g. posted interrupt, EPT cache attribute, etc.). > > Right, the original use case was for KVM to determine whether it needs > to emulate invlpg, so it needs to be aware when an assigned device is invlpg -> wbinvd :) > present and be able to test if DMA for that device is cache coherent. > The user, QEMU, creates a KVM "pseudo" device representing the vfio > group, providing the file descriptor of that group to show ownership. > The ugly symbol_get code is to avoid hard module dependencies, ie. the > kvm module should not pull in or require the vfio module, but vfio will > be present if attempting to register this device. so the symbol_get thing is not about the protocol itself. Whatever protocol is defined, as long as kvm needs to call vfio or ioasid helper function, we need define a proper way to do it. Jason, what's your opinion of alternative option since you dislike symbol_get? > > With kvmgt, the interface also became a way to register the kvm pointer > with vfio for the translation mentioned elsewhere in this thread. > > The PPC/SPAPR support allows KVM to associate a vfio group to an IOMMU > page table so that it can handle iotlb programming from pre-registered > memory without trapping out to userspace. > > > Because KVM deduces some policy based on the fact of assigned device, > > it needs to hold a reference to related vfio group. this part is irrelevant > > to this RFC. > > All of these use cases are related to the IOMMU, whether DMA is > coherent, translating device IOVA to GPA, and an acceleration path to > emulate IOMMU programming in kernel... they seem pretty relevant. One open is whether kvm should hold a device reference or IOASID reference. For DMA coherence, it only matters whether assigned devices are coherent or not (not for a specific address space). For kvmgt, it is for recoding kvm pointer in mdev driver to do write protection. For ppc, it does relate to a specific I/O page table. Then I feel only a part of the protocol will be moved to /dev/ioasid and something will still remain between kvm and vfio? > > > But ARM's VMID usage is related to I/O address space thus needs some > > consideration. Another strange thing is about PPC. Looks it also leverages > > this protocol to do iommu group attach: kvm_spapr_tce_attach_iommu_ > > group. I don't know why it's done through KVM instead of VFIO uAPI in > > the first place. > > AIUI, IOMMU programming on PPC is done through hypercalls, so KVM > needs > to know how to handle those for in-kernel acceleration. Thanks, > ok. Thanks Kevin
