1 | Hi Mostafa, | ||
---|---|---|---|
2 | 1 | ||
3 | > -----Original Message----- | 2 | > -----Original Message----- |
4 | > From: Mostafa Saleh <smostafa@google.com> | 3 | > From: Nicolin Chen <nicolinc@nvidia.com> |
5 | > Sent: Wednesday, November 13, 2024 4:17 PM | 4 | > Sent: Thursday, February 6, 2025 8:33 PM |
6 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> | 5 | > To: Shameerali Kolothum Thodi |
6 | > <shameerali.kolothum.thodi@huawei.com>; Daniel P. Berrangé | ||
7 | > <berrange@redhat.com>; Jason Gunthorpe <jgg@nvidia.com> | ||
7 | > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; | 8 | > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; |
8 | > eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com; | 9 | > eric.auger@redhat.com; peter.maydell@linaro.org; ddutile@redhat.com; |
9 | > nicolinc@nvidia.com; ddutile@redhat.com; Linuxarm | 10 | > Linuxarm <linuxarm@huawei.com>; Wangzhou (B) |
10 | > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; | 11 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; |
11 | > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron | 12 | > Jonathan Cameron <jonathan.cameron@huawei.com>; |
12 | > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org | 13 | > zhangfei.gao@linaro.org; nathanc@nvidia.com |
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 Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote: |
18 | > > On Thu, Feb 06, 2025 at 06:18:14PM +0000, Shameerali Kolothum Thodi | ||
19 | > wrote: | ||
20 | > > | ||
21 | > > > > So even if you invent an iommu ID we cannot accept it as a handle to | ||
22 | > > > > create viommu in iommufd. | ||
23 | > > > | ||
24 | > > > Creating the vIOMMU only happens when the user does a cold/hot | ||
25 | > plug of | ||
26 | > > > a VFIO device. At that time Qemu checks whether the assigned id | ||
27 | > matches | ||
28 | > > > with whatever the kernel tell it. | ||
29 | > > | ||
30 | > > This is not hard up until the guest is started. If you boot a guest | ||
31 | > > without a backing viommu iommufd object then there will be some more | ||
32 | > > complexities. | ||
17 | > | 33 | > |
18 | > On Fri, Nov 08, 2024 at 12:52:37PM +0000, Shameer Kolothum via wrote: | 34 | > Yea, I imagined that things would be complicated with hotplugs.. |
19 | > > Hi, | ||
20 | > > | ||
21 | > > This series adds initial support for a user-creatable "arm-smmuv3-nested" | ||
22 | > > device to Qemu. At present the Qemu ARM SMMUv3 emulation is per | ||
23 | > machine | ||
24 | > > and cannot support multiple SMMUv3s. | ||
25 | > > | ||
26 | > | 35 | > |
27 | > I had a quick look at the SMMUv3 files, as now SMMUv3 supports nested | 36 | > On one hand, I got the part that we need some fixed link forehand |
28 | > translation emulation, would it make sense to rename this? As AFAIU, | 37 | > to ease migration/hotplugs. |
29 | > this is about virt (stage-1) SMMUv3 that is emulated to a guest. | 38 | > |
30 | > Including vSMMU or virt would help distinguish the code, as now | 39 | > On the other hand, all IOMMUFD ioctls need a VFIO device FD, which |
31 | > some new function as smmu_nested_realize() looks confusing. | 40 | > brings the immediate attention that we cannot even decide vSMMU's |
41 | > capabilities being reflected in its IDR/IIDR registers, without a | ||
42 | > coldplug device -- if we boot a VM (one vSMMU<->pSMMU) with only a | ||
43 | > hotplug device, the IOMMU_GET_HW_INFO cannot be done during guest | ||
32 | 44 | ||
33 | Yes. I have noticed that. We need to call it something else to avoid the | 45 | Right. I forgot about the call to smmu_dev_get_info() during the reset. |
34 | confusion. Not sure including "virt" is a good idea as it may indicate virt | 46 | That means we need at least one dev per Guest SMMU during Guest |
35 | machine. Probably "acc" as Nicolin suggested to indicate hw accelerated. | 47 | boot :( |
36 | I will think about a better one. Open to suggestions. | ||
37 | 48 | ||
38 | Thanks, | 49 | Thanks, |
39 | Shameer | 50 | Shameer | diff view generated by jsdifflib |