From: Jason Gunthorpe <jgg@nvidia.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
Eric Auger <eric.auger@redhat.com>,
peter.maydell@linaro.org, shannon.zhaosl@gmail.com,
mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
peterx@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org,
shameerali.kolothum.thodi@huawei.com, jasowang@redhat.com
Subject: Re: [PATCH RFCv1 05/10] hw/arm/virt: Add VIRT_NESTED_SMMU
Date: Thu, 11 Jul 2024 14:57:04 -0300 [thread overview]
Message-ID: <20240711175704.GI1482543@nvidia.com> (raw)
In-Reply-To: <CABJz62PVt9h9776DjXkPYq_Mf+AUJ-0YhnDi-OsaqCqrsrGSQQ@mail.gmail.com>
On Thu, Jul 11, 2024 at 08:48:10AM -0700, Andrea Bolognani wrote:
> IIUC having devices associated to the "correct" SMMU is only a
> requirement for optimal performance, not pure functionality, right?
> In other words, getting the association wrong will make things slower
> but they will keep working.
As part of declaring the iommu as a device libvirt should also specify
the iommu capabilities and features.
There are capabilities that require perfect 1:1 pIOMMU to vIOMMU
matching, or it can't work.
For instance if the pIOMMU has a direct path for invalidations then
the pIOMMU, pPCI, vIOMMU, and vPCI all must be perfectly matched
because the vIOMMU will deliver invalidations directly to a single
pIOMMU with no possibility to steer them to the correct place in
hypervisor SW.
> Is a 1:1 match between pSMMU and vSMMU mandatory? On a system with 4
> SMMUs, could I create a VMs with
>
> vSMMU0 <-> pSMMU0
> vSMMU1 <-> pSMMU1
>
> and another one with
>
> vSMMU0 <-> pSMMU2
> vSMMU1 <-> pSMMU3
This is fine
> assuming of course that devices are assigned to the correct VM?
But devices on pSMMU0 cannot be assigned to the second VM in above
situations.
> How is the association between vSMMU and pSMMU created anyway? Is
> that something that the user can control, or is it done automatically
> somehow?
From a kernel side VIOMMU will be created in IOMMUFD and it will get
as input a reference to a VFIO device. The VIOMMU will be linked to
that VFIO device's pIOMMU.
Also creating a dummy vIOMMU without any devices and thus no way to
reach the pIOMMU is definately "tricky", I'm not sure exactly what is
possible there.
Jason
next prev parent reply other threads:[~2024-07-11 17:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 0:28 [PATCH RFCv1 00/10] hw/arm/virt: Add multiple nested SMMUs Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 01/10] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 02/10] hw/arm/virt: Add iommufd link to virt-machine Nicolin Chen
2024-07-09 9:11 ` Eric Auger
2024-07-09 16:59 ` Nicolin Chen
2024-07-09 17:06 ` Eric Auger
2024-07-09 17:18 ` Nicolin Chen
2024-07-10 2:32 ` Duan, Zhenzhong
2024-06-26 0:28 ` [PATCH RFCv1 03/10] hw/arm/virt: Get the number of host-level SMMUv3 instances Nicolin Chen
2024-07-09 9:20 ` Eric Auger
2024-07-09 17:11 ` Nicolin Chen
2024-07-09 17:22 ` Eric Auger
2024-07-09 18:02 ` Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 04/10] hw/arm/virt: Add an SMMU_IO_LEN macro Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 05/10] hw/arm/virt: Add VIRT_NESTED_SMMU Nicolin Chen
2024-07-09 13:26 ` Eric Auger
2024-07-09 17:59 ` Nicolin Chen
2024-07-11 15:48 ` Andrea Bolognani
2024-07-11 17:57 ` Jason Gunthorpe [this message]
2024-06-26 0:28 ` [PATCH RFCv1 06/10] hw/arm/virt: Assign vfio-pci devices to nested SMMUs Nicolin Chen
2024-07-09 13:32 ` Eric Auger
2024-06-26 0:28 ` [PATCH RFCv1 07/10] hw/arm/virt: Bypass iommu for default PCI bus Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 08/10] hw/arm/virt-acpi-build: Handle reserved bus number of pxb buses Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 09/10] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes Nicolin Chen
2024-06-26 0:28 ` [PATCH RFCv1 10/10] hw/arm/virt-acpi-build: Enable ATS for nested SMMUv3 Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240711175704.GI1482543@nvidia.com \
--to=jgg@nvidia.com \
--cc=abologna@redhat.com \
--cc=anisinha@redhat.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=nicolinc@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=shannon.zhaosl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).