From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: Peter Xu <peterx@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"david@redhat.com" <david@redhat.com>,
"philmd@linaro.org" <philmd@linaro.org>,
"mst@redhat.com" <mst@redhat.com>,
"marcel.apfelbaum@gmail.com" <marcel.apfelbaum@gmail.com>,
Ethan MILON <ethan.milon@eviden.com>
Subject: Re: [PATCH 0/2] Memory and PCI definitions for emulated ATS
Date: Mon, 23 Jun 2025 05:43:06 +0000 [thread overview]
Message-ID: <7ba298b6-13d3-44b4-bc67-5516893a6cb4@eviden.com> (raw)
In-Reply-To: <aFVxwG_O2QkryM6P@x1.local>
Hi Peter
On 20/06/2025 4:35 pm, Peter Xu wrote:
> Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
>
>
> On Fri, Jun 20, 2025 at 05:56:49AM +0000, CLEMENT MATHIEU--DRIF wrote:
>> This short series adds the 'address type' bit (concept from PCIe) to the
>> memory attributes and extends the IOMMUAccessFlags enum. This
>> will be required to implement ATS support for the virtual IOMMUs.
>>
>> Address type: Field present in the PCIe R/W requests, it allows devices to
>> tell the IOMMU if the address provided in the request is physical or not.
>> In other words, it allows the devices to use a physical address obtained
>> via ATS and to prevent the IOMMU from trying to remap it on the fly.
>
> Two pure questions on the flags, could be relevant to spec:
>
>>
>> Additional IOMMU access flags:
>> - Execute Requested
>
> Does this mean that we can start to put code into DMA regions so that
> device can run some day (even if the device may have a core that is totally
> different arch v.s. the host's
AFAIU, the spec is so nonrestrictive about this flag that heterogeneous
arch should not be an issue.
"The definition of what it means for a Function to execute code is
outside the scope of this specification"
>
>> - Privileged Mode Requested
>> - Global
>> - Untranslated Only (cannot be used with 'Address type = translated')
>
> I can understand this with patch 1, but not yet with patch 2.
>
> Patch 1 makes sense to me, IIUC it means the addresses to be used in a pcie
> request will be translated addresses which should bypass IOMMU DMAR.
>
> OTOH, patch 2 added it into iotlb access permissions, which I'm not sure
> what does it mean. Perhaps those addresses can only be translated by ATS
> pre-translation requests, so that DMA on top of them (in IOVA address
> space) will directly fail?
I put this here because the ATS API returns IOMMUTLBEntry structures,
which contain these flags.
The untranslated-only bit is set in ATS responses to inform the device
that the requested address cannot be pre-translated and should be
translated on the fly by the DMA remapping engine. The interrupt range
commonly falls into this category.
>
> Side note, it might still be more reasonable to put these changes into the
> ATS series as the first user of flags.
Yes, I can do that.
However, the ATS series will contain ~10/~12 patches, is it a concern?
Thanks
>cmd
>
> Thanks,
>
>>
>> Clement Mathieu--Drif (2):
>> pci: Add a memory attribute for pre-translated DMA operations
>> memory: Add permissions in IOMMUAccessFlags
>>
>> include/exec/memattrs.h | 3 +++
>> include/hw/pci/pci.h | 9 +++++++++
>> include/system/memory.h | 23 +++++++++++++++++++++--
>> 3 files changed, 33 insertions(+), 2 deletions(-)
>>
>> --
>> 2.49.0
>>
>
> --
> Peter Xu
>
next prev parent reply other threads:[~2025-06-23 5:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 5:56 [PATCH 0/2] Memory and PCI definitions for emulated ATS CLEMENT MATHIEU--DRIF
2025-06-20 5:56 ` [PATCH 1/2] pci: Add a memory attribute for pre-translated DMA operations CLEMENT MATHIEU--DRIF
2025-06-20 5:56 ` [PATCH 2/2] memory: Add permissions in IOMMUAccessFlags CLEMENT MATHIEU--DRIF
2025-06-20 14:35 ` [PATCH 0/2] Memory and PCI definitions for emulated ATS Peter Xu
2025-06-23 5:43 ` CLEMENT MATHIEU--DRIF [this message]
2025-06-23 13:15 ` Peter Xu
2025-06-24 5:02 ` CLEMENT MATHIEU--DRIF
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=7ba298b6-13d3-44b4-bc67-5516893a6cb4@eviden.com \
--to=clement.mathieu--drif@eviden.com \
--cc=david@redhat.com \
--cc=ethan.milon@eviden.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/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).