Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Friday, September 4, 2020 2:42 PM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj,
> Ashok ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil ; Robin
> Murphy ;
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Friday, September 4, 2020 1:31 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj,
> Ashok ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil ; Robin
> Murphy ;
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Wednesday, July 29, 2020 5:37 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj,
> Ashok ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil ; Robin
> Murphy ; Jacob Pa
Hi Joerg,
Thanks for the reply. I will spin another version of the patch addressing your
comments.
> -Original Message-
> From: Joerg Roedel
> Sent: Wednesday, July 22, 2020 6:53 AM
> To: Prakhya, Sai Praneeth
> Cc: Raj, Ashok ; Will Deacon ;
> iommu@lists.linux-fou
>
> Hi Joerg,
>
> > -Original Message-
> > From: Joerg Roedel
> > Sent: Tuesday, June 30, 2020 2:16 AM
> > To: Prakhya, Sai Praneeth
> > Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ;
> > Raj, Ashok ; Will Deacon ;
> > Lu Baolu ;
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Tuesday, June 30, 2020 2:16 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj,
> Ashok ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil ; Robin
> Murphy ; Jacob Pa
Hi Joerg,
> -Original Message-
> From: Prakhya, Sai Praneeth
> Sent: Thursday, June 4, 2020 6:32 PM
> To: iommu@lists.linux-foundation.org
> Cc: Prakhya, Sai Praneeth ; Christoph Hellwig
> ; Joerg Roedel ; Raj, Ashok
> ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil
Hi Baolu,
> -Original Message-
> From: Lu Baolu
> Sent: Thursday, May 28, 2020 7:43 PM
> To: Prakhya, Sai Praneeth ;
> iommu@lists.linux-foundation.org
> Cc: baolu...@linux.intel.com; Christoph Hellwig ; Joerg Roedel
> ; Raj, Ashok ; Will Deacon
> ; Mehta, Sohil
Hi Baolu,
> -Original Message-
> From: Lu Baolu
> Sent: Thursday, May 28, 2020 6:52 PM
> To: Prakhya, Sai Praneeth ;
> iommu@lists.linux-foundation.org
> Cc: baolu...@linux.intel.com; Christoph Hellwig ; Joerg Roedel
> ; Raj, Ashok ; Will Deacon
> ; Mehta, Sohil
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Monday, May 25, 2020 6:57 AM
> To: Prakhya, Sai Praneeth
> Cc: Lu Baolu ; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Sun, May 17,
> -Original Message-
> From: Joerg Roedel
> Sent: Friday, May 15, 2020 8:46 AM
> To: Lu Baolu
> Cc: Prakhya, Sai Praneeth ;
> iommu@lists.linux-foundation.org
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Fri, May 15, 2
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Friday, May 15, 2020 2:59 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Lu Baolu
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Thu, May 14,
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Thursday, May 14, 2020 12:56 PM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Lu Baolu
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Thu, Ma
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Thursday, May 14, 2020 11:33 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Lu Baolu
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Thu, Ma
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Thursday, May 14, 2020 6:13 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Lu Baolu
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Wed, Ma
> On 2020/2/24 16:12, Lu Baolu wrote:
> > On 2020/2/24 15:57, Prakhya, Sai Praneeth wrote:
> >>> On 2020/2/24 15:03, Prakhya, Sai Praneeth wrote:
> >>>>> On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
> >>>>>>>> + list_f
> On 2020/2/24 15:03, Prakhya, Sai Praneeth wrote:
> >> On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
> >>>>> + list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
> >>>>> + struct device *de
> On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
> >>> + list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
> >>> + struct device *dev;
> >>> +
> >>> + dev = grp_dev->dev;
> >
> >> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> >>> The functionality needed for iommu_ops->dev_def_domain_type() is
> >>> already provided by device_def_domain_type() in intel_iommu.c. But,
> >>> every call back function in intel_iommu_ops starts with intel_iommu
> >>> prefix, hence rename
>
> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> > Presently, the default domain of an iommu_group is allocated during
> > boot time (i.e. when a device is being added to a group) and it cannot
> > be changed later. So, the device would typically be either in identity
> > (also known as pass_thro
> > +What: /sys/kernel/iommu_groups//type
> > +Date: February 2020
> > +KernelVersion: v5.6
> > +Contact: Sai Praneeth Prakhya
> > mailto:sai.praneeth.prak...@intel.com>>
> > +Description: Lets the user know the type of
>
> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> > The functionality needed for iommu_ops->dev_def_domain_type() is
> > already provided by device_def_domain_type() in intel_iommu.c. But,
> > every call back function in intel_iommu_ops starts with intel_iommu
> > prefix, hence rename
> > devic
Hi Joerg,
> Presently, the default domain of a group is allocated during boot time and it
> cannot be changed later. So, the device would typically be either in identity
> (pass_through) mode or the device would be in DMA mode as long as the system
> is up and running. There is no way to change th
>
> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> > When user requests kernel to change the default domain type of a group
> > through sysfs, kernel has to make sure that it's ok to change the
> > domain type of every device in the group to the requested domain
> > (every device may not support
> >>> +free_prev_domain:
> >>> + /*
> >>> + * Free the existing default domain and replace it with the newly
> >>> + * created default domain. No need to set group->domain because
> >>> + * __iommu_attach_group() already does it on success.
> >>> + */
> >>> + iommu_domain_free(prev_domain);
> >
Hi Joerg,
Thanks a lot! for the review. I highly appreciate for sparing your time to
review the patch :)
> On Tue, Aug 20, 2019 at 07:42:25PM -0700, Sai Praneeth Prakhya wrote:
> > + /*
> > +* iommu_domain_alloc() takes "struct bus_type" as an argument which
> is
> > +* a member in "st
> On 7/22/19 1:21 PM, Prakhya, Sai Praneeth wrote:
> > Hi Allen,
> >
> >> diff --git a/drivers/iommu/intel-iommu-debugfs.c
> >> b/drivers/iommu/intel- iommu-debugfs.c index
> >> 73a552914455..e31c3b416351 100644
> >> --- a/drivers/iommu/intel-i
> On Tue, Jul 02, 2019 at 06:53:59PM -0700, Sai Praneeth Prakhya wrote:
> > device_def_domain_type() determines the domain type a device could
> > have and it's called only during boot. But, to change the domain of a
> > group through sysfs, kernel has to call this function during runtime.
> > Henc
> On Tue, Jul 02, 2019 at 06:53:58PM -0700, Sai Praneeth Prakhya wrote:
> > Assume a use case where-in the priviliged user would want to use the
> > device in pass-through mode when the device is used for host but would
> > want to switch to dma protected mode when switching for VFIO in user
> > sp
Hi Allen,
> diff --git a/drivers/iommu/intel-iommu-debugfs.c b/drivers/iommu/intel-
> iommu-debugfs.c
> index 73a552914455..e31c3b416351 100644
> --- a/drivers/iommu/intel-iommu-debugfs.c
> +++ b/drivers/iommu/intel-iommu-debugfs.c
> @@ -235,7 +235,7 @@ static void ctx_tbl_walk(struct seq_file *m,
> > The present value shows the existing type of default domain.
> > If user wants to change it (Eg: from DMA to IDENTITY or vice versa), he
> attempts to write the new value.
> > Kernel performs checks to make sure that the driver in unbinded and it's
> > safe
> to change the default domain type.
> > > > Sure! Makes sense.. per-group default domain type sounds good.
> >
> > I am planning to implement an RFC (supporting only runtime case for
> > now) which works as below
> >
> > 1. User unbinds the driver by writing to sysfs 2. User puts a group in
> > pass through mode by writing "1" to
> >
Hi All,
+ Sohil and Rob Clark (as there are dropped from CC'list)
> > > Most iommu vendor drivers have switched from per-device to per-group
> > > domain (a.k.a. default domain). So per-group pass-through mode makes
> more sense?
> > >
> > > By the way, can we extend this to "per-group default do
> > I am working on an IOMMU driver feature that allows a user to specify
> > if the DMA from a device should be translated by IOMMU or not.
> > Presently, we support only all devices or none mode i.e. if user
> > specifies "iommu=pt" [X86] or "iommu.passthrough" [ARM64] through
> > kernel command
Hi All,
I am working on an IOMMU driver feature that allows a user to specify if the
DMA from a device should be translated by IOMMU or not. Presently, we support
only all devices or none mode i.e. if user specifies "iommu=pt" [X86] or
"iommu.passthrough" [ARM64] through kernel command line, al
> > Changes from V2 to V3:
> > --
> > Presently, for V2 patches if kernel command line argument "iommu=pt"
> > is passed, dumping DMAR table seg faults. This happens because in pass
> > through mode (for non-scalable DMAR's) 3rd bit of context entry is set
> > and it is misinter
> > static void ctx_tbl_walk(struct seq_file *m, struct intel_iommu *iommu,
> > u16
> bus)
> > {
> > struct context_entry *context;
> > - u16 devfn;
> > + u16 devfn, pasid_dir_size;
> > + u64 pasid_dir_ptr;
> >
> > for (devfn = 0; devfn < 256; devfn++) {
> > struct tb
> Hi Sai,
>
> On 5/10/19 2:41 AM, Sai Praneeth Prakhya wrote:
> > From: Sai Praneeth
> >
> > Presently, "/sys/kernel/debug/iommu/intel/dmar_translation_struct"
> > file dumps only legacy DMAR table which consists of root table and
> > context table. Scalable mode DMAR table adds PASID directory a
38 matches
Mail list logo
