From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sairaj Kodilkar <sarunkod@amd.com>
Cc: qemu-devel@nongnu.org, alejandro.j.jimenez@oracle.com,
pbonzini@redhat.com, richard.henderson@linaro.org,
philmd@linaro.org, suravee.suthikulpanit@amd.com,
vasant.hegde@amd.com, marcel.apfelbaum@gmail.com,
eduardo@habkost.net, aik@amd.com
Subject: Re: [PATCH v2 2/2] amd_iommu: Support 64 bit address for IOTLB lookup
Date: Tue, 14 Oct 2025 05:05:40 -0400 [thread overview]
Message-ID: <20251014050512-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e4c5d25c-572c-45fe-8e64-b6f141c0f82e@amd.com>
On Tue, Oct 14, 2025 at 02:34:28PM +0530, Sairaj Kodilkar wrote:
>
>
> On 10/13/2025 1:49 PM, Michael S. Tsirkin wrote:
> > On Mon, Oct 13, 2025 at 10:30:46AM +0530, Sairaj Kodilkar wrote:
> > > Physical AMD IOMMU supports up to 64 bits of DMA address. When device tries
> > > to read or write from a given DMA address, IOMMU translates the address
> > > using page table assigned to that device. Since IOMMU uses per device page
> > > tables, the emulated IOMMU should use the cache tag of 68 bits
> > > (64 bit address - 12 bit page alignment + 16 bit device ID).
> > >
> > > Current emulated AMD IOMMU uses GLib hash table to create software iotlb
> > > and uses 64 bit key to store the IOVA and deviceID, which limits the IOVA
> > > to 60 bits. This causes failure while setting up the device when guest is
> > > booted with "iommu.forcedac=1".
> > >
> > > To solve this problem, Use 64 bit IOVA and 16 bit devid as key to store
> > > entries in IOTLB; Use upper 52 bits of IOVA (GFN) and lower 12 bits of
> > > the device ID to construct the 64 bit hash key in order avoid the
> > > truncation as much as possible (reducing hash collisions).
> > >
> > > Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> > > Signed-off-by: Sairaj Kodilkar<sarunkod@amd.com>
> > I am wondering whether we need to limit how much host memory
> > can the shadow take. Because with so many bits, the sky is the limit ...
> > OTOH it's not directly caused by this patch, but it's something
> > we should think about maybe.
>
> I don't think I fully understand this. Do you mean the host memory
> taken by the pages used to build shadow page table ?
the memory used by the hash table.
>
> > Something more to improve:
> >
> >
> > > ---
> > > hw/i386/amd_iommu.c | 57 ++++++++++++++++++++++++++++++---------------
> > > hw/i386/amd_iommu.h | 4 ++--
> > > 2 files changed, 40 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> > > index b194e3294dd7..a218d147e53d 100644
> > > --- a/hw/i386/amd_iommu.c
> > > +++ b/hw/i386/amd_iommu.c
> > > @@ -106,6 +106,11 @@ typedef struct amdvi_as_key {
> > > uint8_t devfn;
> > > } amdvi_as_key;
> > > +typedef struct amdvi_iotlb_key {
> > > + uint64_t gfn;
> > > + uint16_t devid;
> > > +} amdvi_iotlb_key;
> > > +
> > Pls change struct and typedef names to match qemu coding style.
> Thanks
> Sairaj
next prev parent reply other threads:[~2025-10-14 9:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 5:00 [PATCH v2 0/2] amd_iommu: Cleanups and fixes (PART 2) Sairaj Kodilkar
2025-10-13 5:00 ` [PATCH v2 1/2] amd_iommu: Fix handling device on buses != 0 Sairaj Kodilkar
2025-10-13 8:15 ` Michael S. Tsirkin
2025-10-14 5:43 ` Sairaj Kodilkar
2025-10-14 9:02 ` Michael S. Tsirkin
2025-10-14 21:46 ` Alejandro Jimenez
2025-10-15 4:44 ` Sairaj Kodilkar
2025-10-15 7:32 ` Michael S. Tsirkin
2025-10-15 16:19 ` Alejandro Jimenez
2025-10-14 21:28 ` Alejandro Jimenez
2025-10-13 5:00 ` [PATCH v2 2/2] amd_iommu: Support 64 bit address for IOTLB lookup Sairaj Kodilkar
2025-10-13 8:19 ` Michael S. Tsirkin
2025-10-14 8:21 ` Sairaj Kodilkar
2025-10-14 9:04 ` Sairaj Kodilkar
2025-10-14 9:05 ` Michael S. Tsirkin [this message]
2025-10-14 9:12 ` Sairaj Kodilkar
2025-10-14 9:15 ` Michael S. Tsirkin
2025-10-14 21:28 ` Alejandro Jimenez
2025-10-14 21:27 ` [PATCH v2 0/2] amd_iommu: Cleanups and fixes (PART 2) Alejandro Jimenez
2025-10-15 4:41 ` Sairaj Kodilkar
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=20251014050512-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aik@amd.com \
--cc=alejandro.j.jimenez@oracle.com \
--cc=eduardo@habkost.net \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sarunkod@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.