[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to hand
From: |
Eric Auger |
Subject: |
Re: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding |
Date: |
Thu, 14 Nov 2024 11:41:58 +0100 |
User-agent: |
Mozilla Thunderbird |
Hi Shameer,
On 11/14/24 09:48, Shameerali Kolothum Thodi wrote:
>
>> -----Original Message-----
>> From: Nicolin Chen <nicolinc@nvidia.com>
>> Sent: Wednesday, November 13, 2024 6:31 PM
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
>> eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com;
>> ddutile@redhat.com; Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
>> <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
>> Jonathan Cameron <jonathan.cameron@huawei.com>;
>> zhangfei.gao@linaro.org
>> Subject: Re: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions
>> to handle MSI nested binding
>>
>> On Fri, Nov 08, 2024 at 12:52:42PM +0000, Shameer Kolothum wrote:
>>> From: Eric Auger <eric.auger@redhat.com>
>>>
>>> To handle SMMUv3 nested stage support it is practical to expose the
>>> guest with reserved memory regions (RMRs) covering the IOVAs used by
>>> the host kernel to map physical MSI doorbells.
>> There has been an ongoing solution for MSI alternative:
>> https://lore.kernel.org/kvm/cover.1731130093.git.nicolinc@nvidia.com/
>>
>> So, I think we should keep this patch out of this series, instead put it on
>> top
>> of the testing branch.
> Yes. I think then we can support DT solution as well.
>
> On that MSI RFC above, have you seen Eric's earlier/initial proposal to bind
> the Guest MSI in
> nested cases. IIRC, it was providing an IOCTL and then creating a mapping in
> the host.
>
> I think this is the latest on that.
> https://lore.kernel.org/linux-iommu/20210411114659.15051-4-eric.auger@redhat.com/
yes this is the latest before I stopped my VFIO integration efforts.
>
> But not sure, why we then moved to RMR approach. Eric?
This was indeed the 1st integration approach. Using RMR instead was
suggested by Jean-Philippe and I considered it as simpler (because we
needed the SET_MSI_BINDING iotcl) so I changed the approach.
Thanks
Eric
>
> Thanks,
> Shameer
>
- Re: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, (continued)
- Re: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Eric Auger, 2024/11/18
- RE: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Shameerali Kolothum Thodi, 2024/11/18
- Re: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Eric Auger, 2024/11/18
- RE: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Shameerali Kolothum Thodi, 2024/11/20
- Re: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Eric Auger, 2024/11/20
- RE: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Shameerali Kolothum Thodi, 2024/11/20
- RE: [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes, Shameerali Kolothum Thodi, 2024/11/21
[RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding, Shameer Kolothum, 2024/11/08
Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3, Nicolin Chen, 2024/11/12
Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3, Mostafa Saleh, 2024/11/13