| 1 | Hi Mostafa, | ||
|---|---|---|---|
| 2 | 1 | ||
| 3 | > -----Original Message----- | 2 | > -----Original Message----- |
| 4 | > From: Mostafa Saleh <smostafa@google.com> | 3 | > From: Daniel P. Berrangé <berrange@redhat.com> |
| 5 | > Sent: Wednesday, November 13, 2024 4:17 PM | 4 | > Sent: Friday, December 13, 2024 1:20 PM |
| 6 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> | 5 | > To: Jason Gunthorpe <jgg@nvidia.com> |
| 7 | > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; | 6 | > Cc: Shameerali Kolothum Thodi |
| 8 | > eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com; | 7 | > <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; |
| 9 | > nicolinc@nvidia.com; ddutile@redhat.com; Linuxarm | 8 | > qemu-devel@nongnu.org; eric.auger@redhat.com; |
| 10 | > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; | 9 | > peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com; |
| 11 | > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron | 10 | > Linuxarm <linuxarm@huawei.com>; Wangzhou (B) |
| 12 | > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org | 11 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; |
| 12 | > Jonathan Cameron <jonathan.cameron@huawei.com>; | ||
| 13 | > zhangfei.gao@linaro.org | ||
| 13 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable | 14 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable |
| 14 | > nested SMMUv3 | 15 | > nested SMMUv3 |
| 15 | > | 16 | > |
| 16 | > Hi Shameer, | 17 | > On Fri, Dec 13, 2024 at 08:46:42AM -0400, Jason Gunthorpe wrote: |
| 18 | > > On Fri, Dec 13, 2024 at 12:00:43PM +0000, Daniel P. Berrangé wrote: | ||
| 19 | > > > On Fri, Nov 08, 2024 at 12:52:37PM +0000, Shameer Kolothum via wrote: | ||
| 20 | > > > > Hi, | ||
| 21 | > > > > | ||
| 22 | > > > > This series adds initial support for a user-creatable "arm-smmuv3- | ||
| 23 | > nested" | ||
| 24 | > > > > device to Qemu. At present the Qemu ARM SMMUv3 emulation is per | ||
| 25 | > machine | ||
| 26 | > > > > and cannot support multiple SMMUv3s. | ||
| 27 | > > > > | ||
| 28 | > > > > In order to support vfio-pci dev assignment with vSMMUv3, the | ||
| 29 | > physical | ||
| 30 | > > > > SMMUv3 has to be configured in nested mode. Having a pluggable | ||
| 31 | > > > > "arm-smmuv3-nested" device enables us to have multiple vSMMUv3 | ||
| 32 | > for Guests | ||
| 33 | > > > > running on a host with multiple physical SMMUv3s. A few benefits of | ||
| 34 | > doing | ||
| 35 | > > > > this are, | ||
| 36 | > > > | ||
| 37 | > > > I'm not very familiar with arm, but from this description I'm not | ||
| 38 | > > > really seeing how "nesting" is involved here. You're only talking | ||
| 39 | > > > about the host and 1 L1 guest, no L2 guest. | ||
| 40 | > > | ||
| 41 | > > nesting is the term the iommu side is using to refer to the 2 | ||
| 42 | > > dimensional paging, ie a guest page table on top of a hypervisor page | ||
| 43 | > > table. | ||
| 44 | > > | ||
| 45 | > > Nothing to do with vm nesting. | ||
| 17 | > | 46 | > |
| 18 | > On Fri, Nov 08, 2024 at 12:52:37PM +0000, Shameer Kolothum via wrote: | 47 | > Ok, that naming is destined to cause confusion for many, given the |
| 19 | > > Hi, | 48 | > commonly understood use of 'nesting' in the context of VMs... |
| 49 | > | ||
| 20 | > > | 50 | > > |
| 21 | > > This series adds initial support for a user-creatable "arm-smmuv3-nested" | 51 | > > > Also what is the relation between the physical SMMUv3 and the guest |
| 22 | > > device to Qemu. At present the Qemu ARM SMMUv3 emulation is per | 52 | > > > SMMUv3 that's referenced ? Is this in fact some form of host device |
| 23 | > machine | 53 | > > > passthrough rather than nesting ? |
| 24 | > > and cannot support multiple SMMUv3s. | ||
| 25 | > > | 54 | > > |
| 55 | > > It is an acceeleration feature, the iommu HW does more work instead of | ||
| 56 | > > the software emulating things. Similar to how the 2d paging option in | ||
| 57 | > > KVM is an acceleration feature. | ||
| 58 | > > | ||
| 59 | > > All of the iommu series on vfio are creating paravirtualized iommu | ||
| 60 | > > models inside the VM. They access various levels of HW acceleration to | ||
| 61 | > > speed up the paravirtualization. | ||
| 26 | > | 62 | > |
| 27 | > I had a quick look at the SMMUv3 files, as now SMMUv3 supports nested | 63 | > ... describing it as a HW accelerated iommu makes it significantly clearer |
| 28 | > translation emulation, would it make sense to rename this? As AFAIU, | 64 | > to me what this proposal is about. Perhaps the device is better named as |
| 29 | > this is about virt (stage-1) SMMUv3 that is emulated to a guest. | 65 | > "arm-smmuv3-accel" ? |
| 30 | > Including vSMMU or virt would help distinguish the code, as now | ||
| 31 | > some new function as smmu_nested_realize() looks confusing. | ||
| 32 | 66 | ||
| 33 | Yes. I have noticed that. We need to call it something else to avoid the | 67 | Agree. There were similar previous comments from reviewers that current smmuv3 |
| 34 | confusion. Not sure including "virt" is a good idea as it may indicate virt | 68 | already has emulated stage 1 and stage 2 support and refers to that as "nested" |
| 35 | machine. Probably "acc" as Nicolin suggested to indicate hw accelerated. | 69 | in code. So this will be renamed as above. |
| 36 | I will think about a better one. Open to suggestions. | ||
| 37 | 70 | ||
| 38 | Thanks, | 71 | Thanks, |
| 39 | Shameer | 72 | Shameer |
| 73 | |||
| 74 | diff view generated by jsdifflib |