qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).