1 | 1 | ||
---|---|---|---|
2 | > -----Original Message----- | 2 | > -----Original Message----- |
3 | > From: Nicolin Chen <nicolinc@nvidia.com> | 3 | > From: Nathan Chen <nathanc@nvidia.com> |
4 | > Sent: Thursday, January 23, 2025 4:10 AM | 4 | > Sent: Friday, November 22, 2024 1:42 AM |
5 | > To: Donald Dutile <ddutile@redhat.com> | 5 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> |
6 | > Cc: Shameerali Kolothum Thodi | 6 | > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; |
7 | > <shameerali.kolothum.thodi@huawei.com>; eric.auger@redhat.com; Peter | 7 | > eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com; |
8 | > Maydell <peter.maydell@linaro.org>; Jason Gunthorpe <jgg@nvidia.com>; | 8 | > ddutile@redhat.com; Linuxarm <linuxarm@huawei.com>; Wangzhou (B) |
9 | > Daniel P. Berrangé <berrange@redhat.com>; qemu-arm@nongnu.org; | 9 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; |
10 | > qemu-devel@nongnu.org; Linuxarm <linuxarm@huawei.com>; Wangzhou | ||
11 | > (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; | ||
12 | > Jonathan Cameron <jonathan.cameron@huawei.com>; | 10 | > Jonathan Cameron <jonathan.cameron@huawei.com>; |
13 | > zhangfei.gao@linaro.org | 11 | > zhangfei.gao@linaro.org; Nicolin Chen <nicolinc@nvidia.com> |
14 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable | 12 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable |
15 | > nested SMMUv3 | 13 | > nested SMMUv3 |
16 | > | 14 | > |
17 | > Hi Don, | 15 | > >> Also as a heads up, I've added support for auto-inserting PCIe switch |
16 | > >> between the PXB and GPUs in libvirt to attach multiple devices to a | ||
17 | > SMMU | ||
18 | > >> node per libvirt's documentation - "If you intend to plug multiple | ||
19 | > >> devices into a pcie-expander-bus, you must connect a | ||
20 | > >> pcie-switch-upstream-port to the pcie-root-port that is plugged into the | ||
21 | > >> pcie-expander-bus, and multiple pcie-switch-downstream-ports to the | ||
22 | > >> pcie-switch-upstream-port". Future unit-tests should follow this | ||
23 | > >> topology configuration. | ||
24 | > > | ||
25 | > > Ok. Could you please give me an example Qemu equivalent command | ||
26 | > option, | ||
27 | > > if possible, for the above case. I am not that familiar with libvirt | ||
28 | > and I would | ||
29 | > > also like to test the above scenario. | ||
18 | > | 30 | > |
19 | > On Fri, Jan 10, 2025 at 11:05:24PM -0500, Donald Dutile wrote: | 31 | > You can use "-device x3130-upstream" for the upstream switch port, and |
20 | > > On 1/8/25 11:45 PM, Nicolin Chen wrote: | 32 | > "-device xio3130-downstream" for the downstream port: |
21 | > > > On Mon, Dec 16, 2024 at 10:01:29AM +0000, Shameerali Kolothum Thodi | ||
22 | > wrote: | ||
23 | > > > > And patches prior to this commit adds that support: | ||
24 | > > > > 4ccdbe3: ("cover-letter: Add HW accelerated nesting support for arm | ||
25 | > > > > SMMUv3") | ||
26 | > > > > | ||
27 | > > > > Nicolin is soon going to send out those for review. Or I can include | ||
28 | > > > > those in this series so that it gives a complete picture. Nicolin? | ||
29 | > > > | ||
30 | > > > Just found that I forgot to reply this one...sorry | ||
31 | > > > | ||
32 | > > > I asked Don/Eric to take over that vSMMU series: | ||
33 | > > > https://lore.kernel.org/qemu-devel/Zy0jiPItu8A3wNTL@Asurada-Nvidia/ | ||
34 | > > > (The majority of my effort has been still on the kernel side: | ||
35 | > > > previously vIOMMU/vDEVICE, and now vEVENTQ/MSI/vCMDQ..) | ||
36 | > > > | ||
37 | > > > Don/Eric, is there any update from your side? | ||
38 | > > > | ||
39 | > > Apologies for delayed response, been at customer site, and haven't been | ||
40 | > keeping up w/biz email. | ||
41 | > > Eric is probably waiting for me to get back and chat as well. | ||
42 | > > Will look to reply early next week. | ||
43 | > | 33 | > |
44 | > I wonder if we can make some progress in Feb? If so, we can start | 34 | > -device pxb-pcie,bus_nr=250,id=pci.1,bus=pcie.0,addr=0x1 \ |
45 | > to wrap up the iommufd uAPI patches for HWPT, which was a part of | 35 | > -device pcie-root-port,id=pci.2,bus=pci.1,addr=0x0 \ |
46 | > intel's series but never got sent since their emulated series is | 36 | > -device x3130-upstream,id=pci.3,bus=pci.2,addr=0x0 \ |
47 | > seemingly still pending? | 37 | > -device xio3130- |
38 | > downstream,id=pci.4,bus=pci.3,addr=0x0,chassis=17,port=1 \ | ||
39 | > -device vfio-pci,host=0009:01:00.0,id=hostdev0,bus=pci.4,addr=0x0 \ | ||
40 | > -device arm-smmuv3-nested,pci-bus=pci.1 | ||
48 | 41 | ||
49 | I think these are the 5 patches that we require from Intel pass-through series, | 42 | Thanks. Just wondering why libvirt mandates usage of pcie-switch for multiple |
43 | device plugging rather than just using pcie-root-ports? | ||
50 | 44 | ||
51 | vfio/iommufd: Implement [at|de]tach_hwpt handlers | 45 | Please let me if there is any advantage in doing so that you are aware of. |
52 | vfio/iommufd: Implement HostIOMMUDeviceClass::realize_late() handler | ||
53 | HostIOMMUDevice: Introduce realize_late callback | ||
54 | vfio/iommufd: Add properties and handlers to TYPE_HOST_IOMMU_DEVICE_IOMMUFD | ||
55 | backends/iommufd: Add helpers for invalidating user-managed HWPT | ||
56 | |||
57 | See the commits from here, | ||
58 | https://github.com/hisilicon/qemu/commit/bbdc65af38fa5723f1bd9b026e292730901f57b5 | ||
59 | |||
60 | [CC Zhenzhong] | ||
61 | |||
62 | Hi Zhenzhong, | ||
63 | |||
64 | Just wondering what your plans are for the above patches. If it make sense and you | ||
65 | are fine with it, I think it is a good idea one of us can pick up those from that series | ||
66 | and sent out separately so that it can get some review and take it forward. | ||
67 | 46 | ||
68 | Thanks, | 47 | Thanks, |
69 | Shameer | 48 | Shameer |
70 | diff view generated by jsdifflib |