{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":171484007,"defaultBranch":"master","name":"qemu","ownerLogin":"jpemartins","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2019-02-19T14:02:28.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/279189?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1707825470.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"57c8c1853627b80f7f41aa0e0e8e3adc27e20ce2","ref":"refs/heads/iommufd-v5.nodeps","pushedAt":"2024-02-13T11:57:50.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking\n\nThis small series adds support for Dirty Tracking in IOMMUFD backend.\nThe sole reason I still made it RFC, is because of the second patch,\nwhere we are implementing user-managed auto domains.\n\nIn essence it is quite similar to the original IOMMUFD series where we\nwould allocate a HWPT, until we switched later on into a IOAS attach.\nPatch 2 goes into mor detail, but the gist is that there's two modes of\nusing IOMMUFD and switching to user managed auto domains would allow\nduplicating the same flags we have in HWPT into the VFIO IOAS attach.\nWhile it is true that just adding a flag is simpler, it also creates\nduplication and motivates duplicate what hwpt already has.\n\nThe series is divided into:\n\n* Patch 1: Adds a simple helper to get device capabilities;\n\n* Patches 2 - 5: IOMMUFD backend support for dirty tracking;\n\nThe workflow is relatively simple:\n\n1) Probe device and allow dirty tracking in the HWPT\n2) Toggling dirty tracking on/off\n3) Read-and-clear of Dirty IOVAs\n\nThe heuristics selected for (1) were to enable it *if* device supports\nmigration but doesn't support dirty tracking or when IOMMU dirty tracking\nis supported, for the hotplug case where we can add a device without a\ntracker and thus still support migration.\n\nThe unmap case is deferred until further vIOMMU support with migration\nis added[3] which will then introduce the usage of\nIOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR in GET_DIRTY_BITMAP ioctl in the\ndma unmap bitmap flow.\n\n* Patches 6-7: Add disabling of hugepages to allow tracking at base page\nand finally avoid blocking live migration where there's no VF dirty\ntracker, considering that we have IOMMU dirty tracking.\n\nThis series builds on top of Zhengzhong series[0], but only requires the\nfirst 9 patches i.e. up to (\"vfio/pci: Initialize host iommu device\ninstance after attachment\")[1]. This is also stored on github:\nhttps://github.com/jpemartins/qemu/commits/iommufd-v5\n\nNote: While Linux v6.7 has dirty tracking feature, I suggest folks use the\nlatest -rc branch of iommufd kernel tree as there's some fixes needed.\n\nComments and feedback appreciated.\n\nCheers,\n\tJoao\n\nChances since RFCv1[2]:\n* Remove intel/amd dirty tracking emulation enabling\n* Remove the dirtyrate improvement for VF/IOMMU dirty tracking\n[Will pursue these two in separate series]\n* Introduce auto domains support\n* Enforce dirty tracking following the IOMMUFD UAPI for this\n* Add support for toggling hugepages in IOMMUFD\n* Auto enable support when VF supports migration to use IOMMU\nwhen it doesn't have VF dirty tracking\n* Add a parameter to toggle VF dirty tracking\n\n[0] https://lore.kernel.org/qemu-devel/20240201072818.327930-1-zhenzhong.duan@intel.com/\n[1] https://lore.kernel.org/qemu-devel/20240201072818.327930-10-zhenzhong.duan@intel.com/\n[2] https://lore.kernel.org/qemu-devel/20220428211351.3897-1-joao.m.martins@oracle.com/\n[3] https://lore.kernel.org/qemu-devel/20230622214845.3980-1-joao.m.martins@oracle.com/","shortMessageHtmlLink":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking"}},{"before":null,"after":"03018736c04b35b7082fbbb37928e8c816151624","ref":"refs/heads/iommufd-v5","pushedAt":"2024-02-12T13:32:34.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking\n\nThis small series adds support for Dirty Tracking in IOMMUFD backend.\nThe sole reason I still made it RFC, is because of the second patch,\nwhere we are implementing user-managed auto domains.\n\nIn essence it is quite similar to the original IOMMUFD series where we\nwould allocate a HWPT, until we switched later on into a IOAS attach.\nPatch 2 goes into mor detail, but the gist is that there's two modes of\nusing IOMMUFD and switching to user managed auto domains would allow\nduplicating the same flags we have in HWPT into the VFIO IOAS attach.\nWhile it is true that just adding a flag is simpler, it also creates\nduplication and motivates duplicate what hwpt already has.\n\nThe series is divided into:\n\n* Patch 1: Adds a simple helper to get device capabilities;\n\n* Patches 2 - 5: IOMMUFD backend support for dirty tracking;\n\nThe workflow is relatively simple:\n\n1) Probe device and allow dirty tracking in the HWPT\n2) Toggling dirty tracking on/off\n3) Read-and-clear of Dirty IOVAs\n\nThe heuristics selected for (1) were to enable it *if* device supports\nmigration but doesn't support dirty tracking or when IOMMU dirty tracking\nis supported, for the hotplug case where we can add a device without a\ntracker and thus still support migration.\n\nThe unmap case is deferred until further vIOMMU support with migration\nis added[3] which will then introduce the usage of\nIOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR in GET_DIRTY_BITMAP ioctl in the\ndma unmap bitmap flow.\n\n* Patches 6-7: Add disabling of hugepages to allow tracking at base page\nand finally avoid blocking live migration where there's no VF dirty\ntracker, considering that we have IOMMU dirty tracking.\n\nThis series builds on top of Zhengzhong series[0], but only requires the\nfirst 9 patches i.e. up to (\"vfio/pci: Initialize host iommu device\ninstance after attachment\")[1]. This is also stored on github:\nhttps://github.com/jpemartins/qemu/commits/iommufd-v5\n\nNote: While Linux v6.7 has dirty tracking feature, I suggest folks use the\nlatest -rc branch of iommufd kernel tree as there's some fixes needed.\n\nComments and feedback appreciated.\n\nCheers,\n\tJoao\n\nChances since RFCv1[2]:\n* Remove intel/amd dirty tracking emulation enabling\n* Remove the dirtyrate improvement for VF/IOMMU dirty tracking\n[Will pursue these two in separate series]\n* Introduce auto domains support\n* Enforce dirty tracking following the IOMMUFD UAPI for this\n* Add support for toggling hugepages in IOMMUFD\n* Auto enable support when VF supports migration to use IOMMU\nwhen it doesn't have VF dirty tracking\n* Add a parameter to toggle VF dirty tracking\n\n[0] https://lore.kernel.org/qemu-devel/20240201072818.327930-1-zhenzhong.duan@intel.com/\n[1] https://lore.kernel.org/qemu-devel/20240201072818.327930-10-zhenzhong.duan@intel.com/\n[2] https://lore.kernel.org/qemu-devel/20220428211351.3897-1-joao.m.martins@oracle.com/\n[3] https://lore.kernel.org/qemu-devel/20230622214845.3980-1-joao.m.martins@oracle.com/","shortMessageHtmlLink":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking"}},{"before":null,"after":"029937b7c10b69a2a714f05d0aea32bb1234e633","ref":"refs/heads/iommufd-v4","pushedAt":"2023-12-14T20:55:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"cover-letter: x86 iommu dirty tracking emulation\n\nSigned-off-by: Joao Martins ","shortMessageHtmlLink":"cover-letter: x86 iommu dirty tracking emulation"}},{"before":null,"after":"262d5513d434ef833babfed096b28124a110a121","ref":"refs/heads/iommufd-v3","pushedAt":"2023-09-23T01:16:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking\n\nThis series expands IOMMUFD series from Yi and Eric into\nsupporting IOMMU Dirty Tracking. It adds both the emulated\nIOMMUs, as well as IOMMUFD support that exercises said\nemulation (or H/W).\n\nThe series is divided into:\n\n* Patches 1 - 4: x86 IOMMU emulation that performs dirty tracking,\nuseful for a nested guest exercising the IOMMUFD kernel counterpart\nfor coverage and development. The caching of the PASID PTE root flags\nand AMD DTE is not exactly clean.\n\n* Patches 5 - 9: IOMMUFD backend support for dirty tracking;\nSadly this wasn't exactly tested with VF Live Migration, but it adds\n(last 2 patches) a way to measure dirty rate via HMP and QMP.\n\nThe IOMMUFD kernel patches go into extent on what each of the ioctls\ndo, albeit the workflow is relatively simple:\n\n1) Toggling dirty tracking via HWPT_SET_DIRTY or get -ENOTSUPP otherwise\nwhich voids any attempt of walking IO pagetables\n\n2) Read-and-clear of Dirty IOVAs\n\n3) Unmap vIOMMU-backed IOVAs and fetch its dirty state\nright-before-unmap.\n\nThe series is still very RFC, but the intend is mainly to exercise the\nkernel side aside from the selftests that provide some coverage.\n\nComments and feedback appreciated.\n\nCheers,\n\tJoao","shortMessageHtmlLink":"cover-letter: hw/iommufd: IOMMUFD Dirty Tracking"}},{"before":null,"after":"ade4d6d5e18ad37bcd71026c52b6cebaa7151892","ref":"refs/heads/iommufd-v2","pushedAt":"2023-05-18T19:01:28.647Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"[fixup] backends/iommufd: Always enforce dirty tracking\n\nSigned-off-by: Joao Martins ","shortMessageHtmlLink":"[fixup] backends/iommufd: Always enforce dirty tracking"}},{"before":null,"after":"ba93b1e620575fc8f05623cc4f2787db7c23ccfc","ref":"refs/heads/vfio-migration-viommu.alt","pushedAt":"2023-04-17T18:34:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"vfio/common: Add an option to relax iommu usage\n\nSigned-off-by: Joao Martins ","shortMessageHtmlLink":"vfio/common: Add an option to relax iommu usage"}},{"before":"3063b36d9403c9d185a2e06841cdea4d67f1922e","after":"024da897b7fca0255bb9bec871ff5c81744539ce","ref":"refs/heads/vfio-migration-viommu","pushedAt":"2023-04-17T17:00:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"vfio/common: Add an option to relax iommu usage\n\nSigned-off-by: Joao Martins ","shortMessageHtmlLink":"vfio/common: Add an option to relax iommu usage"}},{"before":null,"after":"3063b36d9403c9d185a2e06841cdea4d67f1922e","ref":"refs/heads/vfio-migration-viommu","pushedAt":"2023-04-12T19:29:50.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jpemartins","name":"João Martins","path":"/jpemartins","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/279189?s=80&v=4"},"commit":{"message":"vfio/{common, migration}: Remove migration blocker with vIOMMU\n\nTODO: We still need to add the blocker if the vIOMMU model does not\nsupport the iommu attribute. Hence we keep the functions around, until\nwe make that change.\n\nSigned-off-by: Joao Martins ","shortMessageHtmlLink":"vfio/{common, migration}: Remove migration blocker with vIOMMU"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAD-W3CLQA","startCursor":null,"endCursor":null}},"title":"Activity · jpemartins/qemu"}