From: Fenghua Yu <firstname.lastname@example.org> To: "Liu, Yi L" <email@example.com> Cc: Peter Zijlstra <firstname.lastname@example.org>, "Hansen, Dave" <email@example.com>, H Peter Anvin <firstname.lastname@example.org>, Jean-Philippe Brucker <email@example.com>, "Jiang, Dave" <firstname.lastname@example.org>, "Raj, Ashok" <email@example.com>, x86 <firstname.lastname@example.org>, amd-gfx <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, "Shankar, Ravi V" <firstname.lastname@example.org>, Borislav Petkov <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, "Luck, Tony" <email@example.com>, Felix Kuehling <Felix.Kuehling@amd.com>, linux-kernel <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Pan, Jacob jun" <email@example.com>, David Woodhouse <firstname.lastname@example.org> Subject: Re: [PATCH v6 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Date: Wed, 15 Jul 2020 16:32:00 -0700 [thread overview] Message-ID: <20200715233200.GD64320@romley-ivt3.sc.intel.com> (raw) In-Reply-To: <DM5PR11MB1435394EDA593222F19F3BF8C3610@DM5PR11MB1435.namprd11.prod.outlook.com> Hi, Yi, On Mon, Jul 13, 2020 at 08:25:20PM -0700, Liu, Yi L wrote: > > From: Fenghua Yu <email@example.com> > > Sent: Tuesday, July 14, 2020 7:48 AM > > From: Ashok Raj <firstname.lastname@example.org> Thank you for your comments! But I think we don't need to update this patch because the current text is better than suggested changes. I would rather to keep this patch unchanged. Please see my following explanations for details. > > +(PRI) allow devices to function much the same way as the CPU handling > > +application page-faults. For more information please refer to PCIe > > +specification Chapter 10: ATS Specification. > > + > > nit: may be helpful to mention Chapter 10 of PCIe spec since 4.0. before that, ATS has its > own specification. This doc only refers to the latest specs. Older specs are not useful for this spec. > > +ENQCMD is the glue that ensures applications can directly submit > > +commands to the hardware and also permit hardware to be aware of > > +application context to perform I/O operations via use of PASID. > > + > > maybe a reader will ask about ENQCMDs after reading ENQCMD/S spec. :-) This doc only covers ENQCMD. ENQCMDS is out of scope of this doc. > > +- Allocate the PASID, and program the process page-table (cr3) in the > > +PASID > > + context entries. > > nit: s/PASID context entries/PASID table entries/ Kernel IOMMU does use PASID context. So we would keep the current text. > > > +- Register for mmu_notifier() to track any page-table invalidations to > > +keep > > + the device tlb in sync. For example, when a page-table entry is > > not only device tlb. I guess iotlb is also included. I think they are same/similar concepts. No need to duplicate here. > > +it into the new MSR to communicate the process identity to platform hardware. > > +ENQCMD uses the PASID stored in this MSR to tag requests from this process. > > +When a user submits a work descriptor to a device using the ENQCMD > > +instruction, the PASID field in the descriptor is auto-filled with the > > +value from MSR_IA32_PASID. Requests for DMA from the device are also > > +tagged with the same PASID. The platform IOMMU uses the PASID in the > > not quite get " Requests for DMA from the device are also tagged with the > same PASID" The DMA access from device to the process address space uses the same PASID set up in the MSR. > > > +transaction to perform address translation. The IOMMU api's setup the > > s/api's/apis/ ? > > > +corresponding PASID entry in IOMMU with the process address used by the CPU > > (for e.g cr3 in x86). > > with the process page tables used by the CPU (e.g. the page tables pointed by cr3 in x86). We use address to match the "address space" specified in the term of PASID. page table is implementation details. So we would keep the current text. > > +The MSR must be configured on each logical CPU before any application > > s/MSR/MSR_IA32_PASID/ The MSR refers to MSR_IA32_PASID. We don't need to repeat long "MSR_IA32_PASID" everywhere while a short "the MSR" is better and clear in the doc. > > +thread can interact with a device. Threads that belong to the same > > +process share the same page tables, thus the same MSR value. > > s/MSR/PASID/ The "MSR" is better because we focus on the MSR value here that is set up for each thread. > > > + > > +PASID is cleared when a process is created. The PASID allocation and > > s/PASID/MSR_IA32_PASID/ No. It is PASID that is cleared per process creation. We are not talking about the MSR here although the MSR will cleared as part of process FPU init. > > > +MSR programming may occur long after a process and its threads have been > > created. > > +One thread must call bind() to allocate the PASID for the process. If a > > s/bind()/iommu_sva_bind_device()/ or say "call iommu api to bind a process with > a device." :-) bind() is better because the binding function may be changed (e.g. it was changed in 5.8). People know bind() means binding. Even in the future the binding function is changed again, we don't need to change the text here if using bind(). > > > +thread uses ENQCMD without the MSR first being populated, it will cause #GP. > > +The kernel will fix up the #GP by writing the process-wide PASID into > > +the thread that took the #GP. A single process PASID can be used > > +simultaneously with multiple devices since they all share the same address space. > > simultaneously with multiple devices if they all share the process address > space. Using "since" is better. It explains "why". > > > + > > +New threads could inherit the MSR value from the parent. But this would > > s/MSR/MSR_IA32_PASID/ Ditto. It's unnecessary to use long "MSR_IA32_PASID" everywhere. "The MSR" is concise and clear. Thanks. -Fenghua _______________________________________________ iommu mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-15 23:32 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-13 23:47 [PATCH v6 00/12] x86: tag application address space for devices Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 01/12] iommu: Change type of pasid to u32 Fenghua Yu 2020-07-14 2:45 ` Liu, Yi L 2020-07-14 13:54 ` Fenghua Yu 2020-07-14 13:56 ` Liu, Yi L 2020-07-22 14:03 ` Joerg Roedel 2020-07-22 17:21 ` Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 02/12] iommu/vt-d: Change flags type to unsigned int in binding mm Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Fenghua Yu 2020-07-14 3:25 ` Liu, Yi L 2020-07-15 23:32 ` Fenghua Yu [this message] 2020-07-13 23:47 ` [PATCH v6 04/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 05/12] x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 06/12] x86/msr-index: Define IA32_PASID MSR Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 07/12] mm: Define pasid in mm Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 08/12] fork: Clear PASID for new mm Fenghua Yu 2021-02-24 10:19 ` Jean-Philippe Brucker 2021-02-25 22:17 ` Fenghua Yu 2021-03-01 23:00 ` Jacob Pan 2021-03-02 10:43 ` Jean-Philippe Brucker 2020-07-13 23:48 ` [PATCH v6 09/12] x86/process: Clear PASID state for a newly forked/cloned thread Fenghua Yu 2020-08-01 1:44 ` Andy Lutomirski 2020-07-13 23:48 ` [PATCH v6 10/12] x86/mmu: Allocate/free PASID Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 11/12] sched: Define and initialize a flag to identify valid PASID in the task Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 12/12] x86/traps: Fix up invalid PASID Fenghua Yu 2020-07-31 23:34 ` Andy Lutomirski 2020-08-01 0:42 ` Fenghua Yu 2020-08-03 15:03 ` Dave Hansen 2020-08-03 15:12 ` Andy Lutomirski 2020-08-03 15:19 ` Raj, Ashok 2020-08-03 16:36 ` Dave Hansen 2020-08-03 17:16 ` Andy Lutomirski 2020-08-03 17:34 ` Dave Hansen 2020-08-03 19:24 ` Andy Lutomirski 2020-08-01 1:28 ` Andy Lutomirski 2020-08-03 17:19 ` Fenghua Yu
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=20200715233200.GD64320@romley-ivt3.sc.intel.com \ --firstname.lastname@example.org \ --cc=Felix.Kuehling@amd.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v6 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)' \ /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
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).