Message ID | 1519900415-30314-1-git-send-email-yi.l.liu@linux.intel.com |
---|---|
Headers | show |
Series | Introduce new iommu notifier framework for virt-SVA | expand |
On Thu, Mar 01, 2018 at 06:33:23PM +0800, Liu, Yi L wrote: > This patchset is to introduce a notifier framework for virt-SVA. > You may find virt-SVA design details from the link below. > > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04925.html > > SVA is short for Shared Virtual Addressing. This is also called Shared > Virtual Memory in previous patchsets. However, SVM is confusing as it > can also be short for Secure Virtual Machine. So this patchset use > Shared Virtual Addressing instead of Shared Virtual Memory. And it > would be applied in future (SVA)related patch series as well. > > Qemu has an existing notifier framework based on MemoryRegion, which > are used for MAP/UNMAP. However, it is not well suited for virt-SVA. > Reasons are as below: > - virt-SVA works along with PT = 1 > - if PT = 1 IOMMU MR are disabled so MR notifier are not registered > - new notifiers do not fit nicely in this framework as they need to be > registered even if PT = 1 > - need a new framework to attach the new notifiers > - Additional background can be got from: > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04931.html > > So a new iommu notifier framework is needed. This patchset introduces > a notifier framework based on IOMMUSVAContext. IOMMUSVAContext is > introduced to be an abstract of virt-SVA operations in Qemu. > > Patch Overview: > * 1 - 2: rename existing naming, the IOMMU MemoryRegion Notifier > framework > * 3 - 4: introduce SVA notifier framework based on IOMMUSVAContext > * 5 - 7: introduce PCISVAOps and expose the SVA notfier framework > through hw/pci layer > * 8 - 12: show the usage of SVA notifier in Intel vIOMMU emulator Do you have online branch so that I can check out? The patches are a bit scattered and it's really hard for me to reference things within it... So a complete tree to read would be nice. I roughly went over most of the patches, and the framework you introduced is still not that clear to me. For now I feel like it can be simplified somehow, but I'll hold and speak after I read the whole tree again. Also, it'll be good too if you can always provide some status update of the kernel-counterpart it. Thanks,
> From: Peter Xu [mailto:peterx@redhat.com] > Sent: Tuesday, March 6, 2018 2:56 PM > Subject: Re: [PATCH v3 00/12] Introduce new iommu notifier framework for virt-SVA > > On Thu, Mar 01, 2018 at 06:33:23PM +0800, Liu, Yi L wrote: > > This patchset is to introduce a notifier framework for virt-SVA. > > You may find virt-SVA design details from the link below. > > > > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04925.html > > > > SVA is short for Shared Virtual Addressing. This is also called Shared > > Virtual Memory in previous patchsets. However, SVM is confusing as it > > can also be short for Secure Virtual Machine. So this patchset use > > Shared Virtual Addressing instead of Shared Virtual Memory. And it > > would be applied in future (SVA)related patch series as well. > > > > Qemu has an existing notifier framework based on MemoryRegion, which > > are used for MAP/UNMAP. However, it is not well suited for virt-SVA. > > Reasons are as below: > > - virt-SVA works along with PT = 1 > > - if PT = 1 IOMMU MR are disabled so MR notifier are not registered > > - new notifiers do not fit nicely in this framework as they need to be > > registered even if PT = 1 > > - need a new framework to attach the new notifiers > > - Additional background can be got from: > > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg04931.html > > > > So a new iommu notifier framework is needed. This patchset introduces > > a notifier framework based on IOMMUSVAContext. IOMMUSVAContext is > > introduced to be an abstract of virt-SVA operations in Qemu. > > > > Patch Overview: > > * 1 - 2: rename existing naming, the IOMMU MemoryRegion Notifier > > framework > > * 3 - 4: introduce SVA notifier framework based on IOMMUSVAContext > > * 5 - 7: introduce PCISVAOps and expose the SVA notfier framework > > through hw/pci layer > > * 8 - 12: show the usage of SVA notifier in Intel vIOMMU emulator > > Do you have online branch so that I can check out? yes, I should have pasted it. Here it is: https://github.com/luxis1999/sva_notifier.git > The patches are a bit scattered and it's really hard for me to > reference things within it... So a complete tree to read would be > nice. > > I roughly went over most of the patches, and the framework you > introduced is still not that clear to me. For now I feel like it can > be simplified somehow, but I'll hold and speak after I read the whole > tree again. > > Also, it'll be good too if you can always provide some status update > of the kernel-counterpart it. Good suggestion. For this patchset, it only affects Qemu. Yeah, but for the whole virt-SVA enabling, there is kernel-counterparts. I would do it in the virt-SVA patchset series. Thanks, Yi Liu
On Tue, Mar 06, 2018 at 07:45:39AM +0000, Liu, Yi L wrote: [...] > > Do you have online branch so that I can check out? > > yes, I should have pasted it. Here it is: > https://github.com/luxis1999/sva_notifier.git Thanks. > > > The patches are a bit scattered and it's really hard for me to > > reference things within it... So a complete tree to read would be > > nice. > > > > I roughly went over most of the patches, and the framework you > > introduced is still not that clear to me. For now I feel like it can > > be simplified somehow, but I'll hold and speak after I read the whole > > tree again. > > > > Also, it'll be good too if you can always provide some status update > > of the kernel-counterpart it. > > Good suggestion. For this patchset, it only affects Qemu. Yeah, but for > the whole virt-SVA enabling, there is kernel-counterparts. I would do > it in the virt-SVA patchset series. If you still want to post separately - I'm thinking whether it'll be good you put the vfio changes into the 2nd virt-sva series, since that looks more like in that category. Or say, we can introduce SVAOps/PASIDOps, we implement more vIOMMU invalidation request handling, we call it in IOMMU code, but we don't implement any of the device (vfio) that provide that ops. Or maybe we can just post the whole stuff altogether, since after all these two series are still closely related IMHO (e.g., the SVAOps definition should be closely related to how the first vfio user would like to use it). Only my two cents, and I don't know how other people think. It's up to you after all. :) Thanks,
> From: Peter Xu [mailto:peterx@redhat.com] > Sent: Wednesday, March 7, 2018 1:38 PM > To: Liu, Yi L <yi.l.liu@intel.com> > Cc: Liu, Yi L <yi.l.liu@linux.intel.com>; qemu-devel@nongnu.org; mst@redhat.com; > david@gibson.dropbear.id.au; pbonzini@redhat.com; alex.williamson@redhat.com; > eric.auger.pro@gmail.com; Tian, Kevin <kevin.tian@intel.com>; > jasowang@redhat.com > Subject: Re: [PATCH v3 00/12] Introduce new iommu notifier framework for virt-SVA > > On Tue, Mar 06, 2018 at 07:45:39AM +0000, Liu, Yi L wrote: > > [...] > > > > Do you have online branch so that I can check out? > > > > yes, I should have pasted it. Here it is: > > https://github.com/luxis1999/sva_notifier.git > > Thanks. > > > > > > The patches are a bit scattered and it's really hard for me to > > > reference things within it... So a complete tree to read would be > > > nice. > > > > > > I roughly went over most of the patches, and the framework you > > > introduced is still not that clear to me. For now I feel like it > > > can be simplified somehow, but I'll hold and speak after I read the > > > whole tree again. > > > > > > Also, it'll be good too if you can always provide some status update > > > of the kernel-counterpart it. > > > > Good suggestion. For this patchset, it only affects Qemu. Yeah, but > > for the whole virt-SVA enabling, there is kernel-counterparts. I would > > do it in the virt-SVA patchset series. > > If you still want to post separately - I'm thinking whether it'll be good you put the > vfio changes into the 2nd virt-sva series, since that looks more like in that category. > Or say, we can introduce SVAOps/PASIDOps, we implement more vIOMMU > invalidation request handling, we call it in IOMMU code, but we don't implement any > of the device (vfio) that provide that ops. > > Or maybe we can just post the whole stuff altogether, since after all these two series > are still closely related IMHO (e.g., the SVAOps definition should be closely related to > how the first vfio user would like to use it). > > Only my two cents, and I don't know how other people think. It's up to you after > all. :) Your suggestion is appreciated. My initial plan is: if the SVAOps/PASIDOps and SVAContext proposal is accepted by reviewers. Then I can further merge the two series. So far, still needs to work with David on the SVAContext definition. I'll balance the suggestion from you when sending next version. Thanks, Yi Liu