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