From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
suravee.suthikulpanit@amd.com, wei.huang2@amd.com,
jsnitsel@redhat.com
Subject: Re: [PATCH v2 06/10] iommu/amd: Refactor helper function for setting / clearing GCR3
Date: Wed, 27 Sep 2023 13:45:23 -0300 [thread overview]
Message-ID: <20230927164523.GO13795@ziepe.ca> (raw)
In-Reply-To: <0d47919e-cc2c-d151-f020-e2090fd1c287@amd.com>
On Wed, Sep 27, 2023 at 11:51:20AM +0530, Vasant Hegde wrote:
> >> if (pte == NULL)
> >> return -ENOMEM;
> >>
> >> - *pte = (cr3 & PAGE_MASK) | GCR3_VALID;
> >> + *pte = (gcr3 & PAGE_MASK) | GCR3_VALID;
> >> + __amd_iommu_flush_tlb(dev_data->domain, pasid);
> >
> > This flushing doesn't seem to make sense to me, it shouldn't take in a
> > domain parameter.
> >
> > I'm reading the spec here so I may get this wrong but.. It looks like
> > the IOTLB cache is tagged by (DTE.domain_id, PASID)?
> >
>
> Yeah. It works, but name is confusing.
How does it work? You haven't explained anything about why does it
work.
Nothing guarantees that domain->id is per-device. It is emphatically
not, it is per-domain. It happens to act like it is per-device when
using the DMA API, as DMA API does not share domains across
groups. However iommufd does share domains and so this is not a
correct assumption.
You said below that you think the DTE.domain_id is per-device. I agree
that would fix this bug, if true. If it is to be per-device it should
come from the struct iommu_dev_data, not from the domain->id. This
should happen any time a GCR3 table is in-use. v1 mode is fine to use
a per-domain 'domain_id'.
> amd_iommu_device_flush_pasid_all(dev_data, pasid)
> {
> // Flush domain
> // Flush single device ATS
> }
That would make more logical sense, but it does not resolve the issue
of correctly choosing DTE.domain_id so the cache tags don't alias.
Jason
next prev parent reply other threads:[~2023-09-27 16:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 17:40 [PATCH v2 00/10] iommu/amd: SVA Support (part 3) - refactor support for GCR3 table Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 01/10] iommu/amd: Use struct protection_domain in helper functions Vasant Hegde
2023-08-23 16:42 ` Jason Gunthorpe
2023-08-24 6:12 ` Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 02/10] iommu/amd: Introduce get_amd_iommu_from_dev() Vasant Hegde
2023-09-13 14:42 ` Jason Gunthorpe
2023-09-14 8:21 ` Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 03/10] iommu/amd: Introduce struct protection_domain.pd_mode Vasant Hegde
2023-09-13 14:42 ` Jason Gunthorpe
2023-08-16 17:40 ` [PATCH v2 04/10] iommu/amd: Introduce per-device GCR3 table Vasant Hegde
2023-09-13 14:43 ` Jason Gunthorpe
2023-09-14 8:24 ` Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 05/10] iommu/amd: Use protection_domain.flags to check page table mode Vasant Hegde
2023-09-13 14:43 ` Jason Gunthorpe
2023-08-16 17:40 ` [PATCH v2 06/10] iommu/amd: Refactor helper function for setting / clearing GCR3 Vasant Hegde
2023-09-13 15:12 ` Jason Gunthorpe
2023-09-27 6:21 ` Vasant Hegde
2023-09-27 16:45 ` Jason Gunthorpe [this message]
2023-10-10 6:02 ` Vasant Hegde
2023-10-10 14:38 ` Jason Gunthorpe
2023-10-13 15:45 ` Vasant Hegde
2023-10-13 16:01 ` Jason Gunthorpe
2023-08-16 17:40 ` [PATCH v2 07/10] iommu/amd: Refactor helper function for attaching / detaching device Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 08/10] iommu/amd: Refactor protection_domain helper functions Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 09/10] iommu/amd: Refactor GCR3 table " Vasant Hegde
2023-08-16 17:40 ` [PATCH v2 10/10] iommu/amd: Remove unused GCR3 table parameters from struct protection_domain Vasant Hegde
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=20230927164523.GO13795@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
--cc=wei.huang2@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.