qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nested-smmuv3 topic for QEMU/libvirt, Nov 2024


From: Eric Auger
Subject: Re: nested-smmuv3 topic for QEMU/libvirt, Nov 2024
Date: Tue, 19 Nov 2024 09:17:39 +0100
User-agent: Mozilla Thunderbird

Hi Zhenzhong,

On 11/19/24 08:07, Duan, Zhenzhong wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Tuesday, November 19, 2024 2:00 AM
>> Subject: Re: nested-smmuv3 topic for QEMU/libvirt, Nov 2024
>>
>> Hi Nicolin,
>>
>> On 11/7/24 21:31, Nicolin Chen wrote:
>>> Hi Eric,
>>>
>>> On Thu, Nov 07, 2024 at 12:11:05PM +0100, Eric Auger wrote:
>>>> On 11/1/24 05:09, Nicolin Chen wrote:
>>>>> Hi,
>>>>>
>>>>> This is a continued discussion following previous month's:
>>>>> https://lore.kernel.org/qemu-devel/Zvr%2Fbf7KgLN1cjOl@Asurada-Nvidia/
>>>>>
>>>>> Kernel changes are getting closer to merge, as Jason's planning to
>>>>> take vIOMMU series and smmuv3_nesting series into the iommufd tree:
>>>>> https://lore.kernel.org/all/cover.1730313494.git.nicolinc@nvidia.com/
>>>>> https://lore.kernel.org/all/cover.1730313494.git.nicolinc@nvidia.com/
>>>>> https://lore.kernel.org/all/0-v4-9e99b76f3518+3a8-
>> smmuv3_nesting_jgg@nvidia.com/
>>>>> So, I think it's probably a good time to align with each others and
>>>>> talk about kicking off some QEMU upstream work in the month ahead.
>>>>>
>>>>> @Shameer,
>>>>> Do you have some update on the pluggable smmuv3 module?
>>>>>
>>>>> Updates on my side:
>>>>> 1) I have kept uAPI updated to the latest version and verified too.
>>>>>    There should be some polishing changes depending on how the basic
>>>>>    nesting infrastructure would look like from Intel/Duan's work.
>>>>> 2) I got some help from NVIDIA folks for the libvirt task. And they
>>>>>    have done some drafting and are now verifying the PCI topology
>>>>>    with "iommu=none".
>>>>>
>>>>> Once the pluggable smmuv3 module is ready to test, we will make some
>>>>> change to libvirt for that and drop the auto-assigning patches from
>>>>> the VIRT code, so as to converge for a libvirt+QEMU test.
>>>>>
>>>>> FWIW, Robin requested a different solution for MSI mapping [1], v.s.
>>>>> the RMR one that we have been using since Eric's work. I drafted a
>>>>> few VFIO/IOMMUFD patches for that, yet paused for getting the vIOMMU
>>>>> series merged to this kernel cycle. I plan to continue in Nov/Dec.
>>>>> So, for the near term we will continue with the RMR solution, until
>>>>> we have something solid later.
>>>>>
>>>>> [1] https://lore.kernel.org/linux-iommu/ZrVN05VylFq8lK4q@Asurada-Nvidia/
>>>> At Red Hat we may find some cycles to resume working on the QEMU
>>>> integration. Please can you sketch some tasks we could carry out in
>>>> coordination with you and Shameer? Adding Don in the loop.
>>> That is great!
>>>
>>> So, given that Shameer is working on pluggable module part and we
>>> have folks working on libvirt. I think the only big thing here is
>>> the SMMUv3 series itself. Please refer to the changes in the link:
>>>  - cover-letter: Add HW accelerated nesting support for arm SMMUv3
>>>  - https://github.com/nicolinc/qemu/commits/wip/for_smmuv3_nesting-v4/
>> Looking at your branch I see the following series (marked with cover-letter)
>> *
>>
>>  *
>>
>>    cover-letter: Add RMR WAR for MSI mappings (based on former RMR flat
>>    mapping and not related to *[PATCH RFCv1 0/7] vfio: Allow userspace
>>    to specify the address for each MSI vector
>>    <https://lore.kernel.org/kvm/cover.1731130093.git.nicolinc@nvidia.com/#r>
>>    I guess)*
>>
>>  *
>>
>>    cover-letter: hw/arm/virt: Add multiple nested SMMUs (Nicolin ->
>>    Shameer)
>>
>>  *
>>
>>    cover-letter: Add HW accelerated nesting support for arm SMMUv3
>>    (Nicolin)
>>
>>  *
>>
>>    cover-letter: Add VIOMMU infrastructure support (Nicolin)
>>
>>  *
>>
>>    cover-letter: intel_iommu: Enable stage-1 translation for
>>    passthrough device (Zhenzhong)
>>
>>  *
>>
>>    cover-letter: intel_iommu: Enable stage-1 translation for emulated
>>    device (Zhenzhong)
>>
>> The last one is covered by *[PATCH v5 00/20] intel_iommu: Enable stage-1
>> translation for emulated device
>> <https://lore.kernel.org/all/20241111083457.2090664-1-
>> zhenzhong.duan@intel.com/#r>
>> *
>>
>> *I see there is a reference to *"Enable stage-1 translation for
>> passthrough device" series but has it been posted for review? Adding
>> Zhenzhong in copy.
> There is an RFCv1 posted upstream which is a combination of
> " intel_iommu: Enable stage-1 translation for emulated device" and
> " intel_iommu: Enable stage-1 translation for passthrough device".
> Link: https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg02740.html
>
> If you means the split version, not sent yet. Plan it after the series about
> emulated device is accepted.
OK thank you very much for the link and confirmation.

Eric
>
> Thanks
> Zhenzhong
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]