| 1 | Hi Nathan, | ||
|---|---|---|---|
| 2 | 1 | ||
| 3 | > -----Original Message----- | 2 | > -----Original Message----- |
| 4 | > From: Nathan Chen <nathanc@nvidia.com> | 3 | > From: Nicolin Chen <nicolinc@nvidia.com> |
| 5 | > Sent: Friday, December 13, 2024 1:02 AM | 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 | > ddutile@redhat.com; Linuxarm <linuxarm@huawei.com>; Wangzhou (B) | 10 | > Linuxarm <linuxarm@huawei.com>; Wangzhou (B) |
| 10 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; | 11 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; |
| 11 | > Jonathan Cameron <jonathan.cameron@huawei.com>; | 12 | > Jonathan Cameron <jonathan.cameron@huawei.com>; |
| 12 | > zhangfei.gao@linaro.org; Nicolin Chen <nicolinc@nvidia.com> | 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 | > |
| 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. | ||
| 16 | > | 33 | > |
| 17 | > >with an error message indicating DMA mapping failed for the | 34 | > Yea, I imagined that things would be complicated with hotplugs.. |
| 18 | > passthrough >devices. | ||
| 19 | > | 35 | > |
| 20 | > A correction - the message indicates UEFI failed to find a mapping for | 36 | > On one hand, I got the part that we need some fixed link forehand |
| 21 | > the boot partition ("map: no mapping found"), not that DMA mapping | 37 | > to ease migration/hotplugs. |
| 22 | > failed. But earlier EDK debug logs still show PCI host bridge resource | 38 | > |
| 23 | > conflicts for the passthrough devices that seem related to the VM boot | 39 | > On the other hand, all IOMMUFD ioctls need a VFIO device FD, which |
| 24 | > failure. | 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 | ||
| 25 | 44 | ||
| 26 | I have tried a 2023 version EFI which works. And for more recent tests I am | 45 | Right. I forgot about the call to smmu_dev_get_info() during the reset. |
| 27 | using a one built directly from, | 46 | That means we need at least one dev per Guest SMMU during Guest |
| 28 | https://github.com/tianocore/edk2.git master | 47 | boot :( |
| 29 | |||
| 30 | Commit: 0f3867fa6ef0("UefiPayloadPkg/UefiPayloadEntry: Fix PT protection | ||
| 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 | 48 | ||
| 44 | Thanks, | 49 | Thanks, |
| 45 | Shameer | 50 | Shameer | diff view generated by jsdifflib |