| 1 | Hi Nathan, | 1 | Hi Nicolin, |
|---|---|---|---|
| 2 | 2 | ||
| 3 | > -----Original Message----- | 3 | > -----Original Message----- |
| 4 | > From: Nathan Chen <nathanc@nvidia.com> | 4 | > From: Nicolin Chen <nicolinc@nvidia.com> |
| 5 | > Sent: Friday, December 13, 2024 1:02 AM | 5 | > Sent: Wednesday, February 5, 2025 12:09 AM |
| 6 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> | 6 | > To: Shameerali Kolothum Thodi |
| 7 | > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; | 7 | > <shameerali.kolothum.thodi@huawei.com>; Eric Auger |
| 8 | > eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com; | 8 | > <eric.auger@redhat.com> |
| 9 | > ddutile@redhat.com; Linuxarm <linuxarm@huawei.com>; Wangzhou (B) | 9 | > Cc: ddutile@redhat.com; Peter Maydell <peter.maydell@linaro.org>; Jason |
| 10 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; | 10 | > Gunthorpe <jgg@nvidia.com>; Daniel P. Berrangé <berrange@redhat.com>; |
| 11 | > Jonathan Cameron <jonathan.cameron@huawei.com>; | 11 | > qemu-arm@nongnu.org; qemu-devel@nongnu.org; Linuxarm |
| 12 | > zhangfei.gao@linaro.org; Nicolin Chen <nicolinc@nvidia.com> | 12 | > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; |
| 13 | > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron | ||
| 14 | > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org | ||
| 13 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable | 15 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable |
| 14 | > nested SMMUv3 | 16 | > nested SMMUv3 |
| 15 | > | 17 | > |
| 18 | > On Tue, Feb 04, 2025 at 06:49:15PM +0100, Eric Auger wrote: | ||
| 19 | > > > In summary, we will have the following series: | ||
| 20 | > > > 1) HWPT uAPI patches in backends/iommufd.c (Zhenzhong or Shameer) | ||
| 21 | > > > https://lore.kernel.org/qemu- | ||
| 22 | > devel/SJ0PR11MB6744943702EB5798EC9B3B9992E02@SJ0PR11MB6744.nam | ||
| 23 | > prd11.prod.outlook.com/ | ||
| 24 | > > > 2) vIOMMU uAPI patches in backends/iommufd.c (I will rebase/send) | ||
| 16 | > | 25 | > |
| 17 | > >with an error message indicating DMA mapping failed for the | 26 | > > for 1 and 2, are you taking about the "Add VIOMMU infrastructure |
| 18 | > passthrough >devices. | 27 | > support |
| 28 | > > " series in Shameer's branch: private-smmuv3-nested-dev-rfc-v1. | ||
| 29 | > > Sorry I may instead refer to NVidia or Intel's branch but I am not sure | ||
| 30 | > > about the last ones. | ||
| 19 | > | 31 | > |
| 20 | > A correction - the message indicates UEFI failed to find a mapping for | 32 | > That "vIOMMU infrastructure" is for 2, yes. |
| 21 | > the boot partition ("map: no mapping found"), not that DMA mapping | 33 | > |
| 22 | > failed. But earlier EDK debug logs still show PCI host bridge resource | 34 | > For 1, it's inside the Intel's series: |
| 23 | > conflicts for the passthrough devices that seem related to the VM boot | 35 | > "cover-letter: intel_iommu: Enable stage-1 translation for passthrough |
| 24 | > failure. | 36 | > device" |
| 37 | > | ||
| 38 | > So, we need to extract them out and make it separately.. | ||
| 39 | > | ||
| 40 | > > > 3) vSMMUv3 patches for HW-acc/nesting (Hoping Don/you could take | ||
| 41 | > over) | ||
| 42 | > > We can start sending it upstream assuming we have a decent test | ||
| 43 | > environment. | ||
| 44 | > > | ||
| 45 | > > However in | ||
| 46 | > > | ||
| 47 | > https://lore.kernel.org/all/329445b2f68a47269292aefb34584375@huawei.c | ||
| 48 | > om/ | ||
| 49 | > > | ||
| 50 | > > Shameer suggested he may include it in his SMMU multi instance series. | ||
| 51 | > > What do you both prefer? | ||
| 52 | > | ||
| 53 | > Sure, I think it's good to include those patches, | ||
| 25 | 54 | ||
| 26 | I have tried a 2023 version EFI which works. And for more recent tests I am | 55 | One of the feedback I received on my series was to rename "arm-smmuv3-nested" |
| 27 | using a one built directly from, | 56 | to "arm-smmuv3-accel" and possibly rename function names to include "accel' as well |
| 28 | https://github.com/tianocore/edk2.git master | 57 | and move those functions to a separate "smmuv3-accel.c" file. I suppose that applies to |
| 58 | the " Add HW accelerated nesting support for arm SMMUv3" series as well. | ||
| 29 | 59 | ||
| 30 | Commit: 0f3867fa6ef0("UefiPayloadPkg/UefiPayloadEntry: Fix PT protection | 60 | Is that fine with you? |
| 31 | in 5 level paging" | ||
| 32 | |||
| 33 | With both, I don’t remember seeing any boot failure and the above UEFI | ||
| 34 | related "map: no mapping found" error. But the Guest kernel at times | ||
| 35 | complaints about pci bridge window memory assignment failures. | ||
| 36 | ... | ||
| 37 | pci 0000:10:01.0: bridge window [mem size 0x00200000 64bit pref]: can't assign; no space | ||
| 38 | pci 0000:10:01.0: bridge window [mem size 0x00200000 64bit pref]: failed to assign | ||
| 39 | pci 0000:10:00.0: bridge window [io size 0x1000]:can't assign; no space | ||
| 40 | ... | ||
| 41 | |||
| 42 | But Guest still boots and worked fine so far. | ||
| 43 | 61 | ||
| 44 | Thanks, | 62 | Thanks, |
| 45 | Shameer | 63 | Shameer | diff view generated by jsdifflib |