On Mon, Jul 06, 2020 at 04:32:40PM -0700, Rajat Jain wrote:
> device_attach() returning failure indicates a driver error while trying to
> probe the device. In such a scenario, the PCI device should still be added
> in the system and be visible to the user.
>
> This patch partially reverts:
> comm
On Mon, Jul 06, 2020 at 12:42:27PM -0700, Jonathan Lemon wrote:
> On Mon, Jun 29, 2020 at 03:03:56PM +0200, Christoph Hellwig wrote:
> > Add a new API to check if calls to dma_sync_single_for_{device,cpu} are
> > required for a given DMA streaming mapping.
> >
> > +::
> > +
> > + bool
> > + dm
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v3: print warning if ACS_TB not supported on external-facing/untrusted ports.
Minor code comments fixes.
v2: Commit log change
drivers/pci/pci.c| 7 +++
dri
On Fri, Jul 03, 2020 at 05:25:48PM +0100, Will Deacon wrote:
> The IOMMU_SYS_CACHE_ONLY flag was never exposed via the DMA API and
> has no in-tree users. Remove it.
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-fo
…
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -2798,7 +2798,7 @@ static int vfio_iommu_type1_dma_rw_chunk
…
> - bool kthread = current->mm == NULL;
> + bool kthread_load_mm;
> size_t offset;
How do you think about to reduce the scope for such variables?
https://refactoring.com/catal
On Wed, Jul 1, 2020 at 10:23 PM Oliver O'Halloran wrote:
>
> On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
> >
> > *snip*
> >
> > > > I guess it would make sense to have an attribute for user space to
> > > > write to in order to make the kernel reject device plug-in events
> > > > coming from
The "ExternalFacingPort" devices (root ports) are internal devices that
sit on the internal system fabric. Ref:
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports
Currently they were treated (marked as untrusted) at par with other
external devices downstream thos
Move pci_enable_acs() and the functions it depends on, further up in the
source code to avoid having to forward declare it when we make it static
in near future (next patch).
No functional changes intended.
Signed-off-by: Rajat Jain
---
v3: Initial version of the patch, created per Bjorn's sugge
Currently ACS capabiity is being looked up at a number of places. Read and
store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v3: fix commit log, remove forward declation of static function
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2 +-
dri
Dear Baolu,
On Tue, Jun 30, 2020 at 3:52 PM Lu Baolu wrote:
>
> Hi Koba,
>
> On 2020/6/30 15:31, Koba Ko wrote:
> > On Mon, Jun 15, 2020 at 3:20 PM Lu Baolu wrote:
> >>
> >> Hi Koba Ko,
> >>
> >> On 2020/6/15 11:19, Koba Ko wrote:
> >>> hi All,
> >>> I have a machine and there's only intel gpu.
>
On Tue, 7 Jul 2020 08:31:41 +0800 Yan Zhao wrote:
>
> I think "current->mm == NULL" in itself implies kthread and not use_mm,
> as a user thread is not able to have "current->mm == NULL", right?
Nope, it's the fix target as checking the current mm does not make
sense without current being kthrea
The normal domain at(de)tach is parallel with aux-domain at(de)tach. In
another word, once an iommu_group is attached through the normal domain
attach api's, it should not go through the aux-domain at(de)tach api's
until the domain is detached. And, vice versa.
Currently, we prohibit an iommu_grou
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
- Create a group for mdev with iommu_group_alloc();
- Add the device to the group with
group = iommu_group_alloc();
if (
This series aims to enhance the iommu_aux_at(de)tach_device() api's
so that some generic iommu api's like iommu_get_domain_for_dev() could
also work for vfio/mdev device.
The initial version of this series was post at
https://lkml.org/lkml/2020/6/26/1118
This version is evolved according to Robi
On 7/2/20 10:36 AM, Lu Baolu wrote:
Hi Robin,
On 7/1/20 8:18 PM, Robin Murphy wrote:
On 2020-07-01 08:32, Lu Baolu wrote:
Hi Robin,
On 2020/7/1 0:51, Robin Murphy wrote:
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wr
On Mon, 6 Jul 2020 16:04:13 +0200 Markus Elfring wrote:
>
> Can another design approach make sense here?
>
> + bool thread_use_mm = ((current->flags & PF_KTHREAD) && !current->mm);
> + if (thread_use_mm)
Good. See below.
>
>
> > kthread_use_mm(mm);
--- a/drivers/vfio/vf
On 03/06/2020 14:13, Alexey Kardashevskiy wrote:
>
>
> On 09/05/2020 18:19, Christoph Hellwig wrote:
>> On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 17/04/2020 17:58, Christoph Hellwig wrote:
On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashe
On Mon, Jul 06, 2020 at 06:49:15PM +0800, Hillf Danton wrote:
>
> It's incorrect to tell out if a task is kthread without checking
> PF_KTHREAD at all.
>
> What's also fixed, if no need to be in a seperate patch, is to
> invoke kthread_use_mm() without checking the current mm first as
> the kthre
From: Liu Yi L
For guest SVA usage, in order to optimize for less VMEXIT, guest request
of IOTLB flush also includes device TLB.
On the host side, IOMMU driver performs IOTLB and implicit devTLB
invalidation. When PASID-selective granularity is requested by the guest
we need to derive the equiva
For the unlikely use case where multiple aux domains from the same pdev
are attached to a single guest and then bound to a single process
(thus same PASID) within that guest, we cannot easily support this case
by refcounting the number of users. As there is only one SL page table
per PASID while we
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. This is more efficient in that multiple
PASIDs can b
From: Liu Yi L
Address information for device TLB invalidation comes from userspace
when device is directly assigned to a guest with vIOMMU support.
VT-d requires page aligned address. This patch checks and enforce
address to be page aligned, otherwise reserved bits can be set in the
invalidation
From: Liu Yi L
Set proper masks to avoid invalid input spillover to reserved bits.
Acked-by: Lu Baolu
Reviewed-by: Eric Auger
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/linux/intel-iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linu
Hi Baolu and all,
This is a series to address some of the issues we found in vSVA support.
Most of the patches deal with exception handling, we also removed some bits
that are not currently supported.
Many thanks to Kevin Tian's review.
Jacob & Yi
Changelog:
v4 Address reviews from Eric A
Global pages support is removed from VT-d spec 3.0 for dev TLB
invalidation. This patch is to remove the bits for vSVA. Similar change
already made for the native SVA. See the link below.
Link: https://lkml.org/lkml/2019/8/26/651
Acked-by: Lu Baolu
Reviewed-by: Eric Auger
Signed-off-by: Jacob Pa
For guest requested IOTLB invalidation, address and mask are provided as
part of the invalidation data. VT-d HW silently ignores any address bits
below the mask. SW shall also allow such case but give warning if
address does not align with the mask. This patch relax the fault
handling from error to
On Thu, 2 Jul 2020 09:16:22 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 7/1/20 5:33 PM, Jacob Pan wrote:
> > Global pages support is removed from VT-d spec 3.0 for dev TLB
> > invalidation. This patch is to remove the bits for vSVA. Similar
> > change already made for the native SVA. See the link
Hello Bjorn,
On Mon, Jul 6, 2020 at 4:30 PM Bjorn Helgaas wrote:
>
> On Mon, Jul 06, 2020 at 03:31:47PM -0700, Rajat Jain wrote:
> > On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
> > > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
>
> > > > -static void pci_acpi_set_untrusted
On Tue, Jun 30, 2020 at 1:02 AM Greg Kroah-Hartman
wrote:
>
> On Mon, Jun 29, 2020 at 09:49:40PM -0700, Rajat Jain wrote:
> > device_attach() returning failure indicates a driver error while trying to
> > probe the device. In such a scenario, the PCI device should still be added
> > in the system
device_attach() returning failure indicates a driver error while trying to
probe the device. In such a scenario, the PCI device should still be added
in the system and be visible to the user.
This patch partially reverts:
commit ab1a187bba5c ("PCI: Check device_attach() return value always")
Sign
On Mon, Jul 06, 2020 at 03:31:47PM -0700, Rajat Jain wrote:
> On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
> > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > > -static void pci_acpi_set_untrusted(struct pci_dev *dev)
> > > +static void pci_acpi_set_external_facing(struct p
On Thu, 2 Jul 2020 09:50:19 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 7/1/20 5:33 PM, Jacob Pan wrote:
> > From: Liu Yi L
> >
> > Address information for device TLB invalidation comes from userspace
> > when device is directly assigned to a guest with vIOMMU support.
> > VT-d requires page al
On Mon, Jul 6, 2020 at 10:07 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v2: Commit log change
> >
> >
On Mon, Jul 06, 2020 at 03:16:42PM -0700, Rajat Jain wrote:
> On Mon, Jul 6, 2020 at 8:58 AM Bjorn Helgaas wrote:
> > On Mon, Jun 29, 2020 at 09:49:37PM -0700, Rajat Jain wrote:
> > > +static void pci_enable_acs(struct pci_dev *dev);
> >
> > I don't think we need this forward declaration, do we?
On Mon, Jul 6, 2020 at 9:45 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v2: Commit log change
> >
> >
Hello,
On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > The "ExternalFacing" devices (root ports) are still internal devices that
> > sit on the internal system fabric and thus trusted. Currently they were
> > being marked unt
On Sat, Jul 4, 2020 at 4:44 AM Pavel Machek wrote:
>
> Hi!
>
> > * The first 3 patches tighten the PCI security using ACS, and take care
> > of a border case.
> > * The 4th patch takes care of PCI bug.
> > * 5th and 6th patches expose a device's location into the sysfs to allow
> > admin to ma
Hi Bjorn,
Thanks for taking a look.
On Mon, Jul 6, 2020 at 8:58 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:37PM -0700, Rajat Jain wrote:
> > Currently this is being looked up at a number of places. Read and store it
> > once at bootup so that it can be used by all later.
>
> Write
On Thu, 2 Jul 2020 10:39:26 +0200
Auger Eric wrote:
> Hi Jacob, Yi,
> On 7/1/20 5:33 PM, Jacob Pan wrote:
> > From: Liu Yi L
> >
> > For guest SVA usage, in order to optimize for less VMEXIT, guest
> > request of IOTLB flush also includes device TLB.
> >
> > On the host side, IOMMU driver perf
Hi Jean,
Thanks for the feedback, please see replies inline.
On Mon, 6 Jul 2020 12:30:41 +0200
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> On Thu, Jul 02, 2020 at 06:48:25AM -0700, Jacob Pan wrote:
> > Hi Jean,
> >
> > Just realized I should send this to your Linaro account instead of
> > ARM
On Wed, Jul 01, 2020 at 10:46:40AM +0100, Robin Murphy wrote:
> On 2020-06-30 20:08, Jonathan Lemon wrote:
> > On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
> > > On 2020-06-27 08:02, Christoph Hellwig wrote:
> > > > On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
>
On Mon, Jun 29, 2020 at 03:03:56PM +0200, Christoph Hellwig wrote:
> Add a new API to check if calls to dma_sync_single_for_{device,cpu} are
> required for a given DMA streaming mapping.
>
> +::
> +
> + bool
> + dma_need_sync(struct device *dev, dma_addr_t dma_addr);
> +
> +Returns %true i
On Mon, Jul 06, 2020 at 11:41:26AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 30, 2020 at 09:55:54AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > > The "ExternalFacing" devices (root ports) are still internal devices that
> > > sit on the inter
On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> When enabling ACS, enable translation blocking for external facing ports
> and untrusted devices.
>
> Signed-off-by: Rajat Jain
> ---
> v2: Commit log change
>
> drivers/pci/pci.c| 4
> drivers/pci/quirks.c | 11 ++
On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> When enabling ACS, enable translation blocking for external facing ports
> and untrusted devices.
>
> Signed-off-by: Rajat Jain
> ---
> v2: Commit log change
>
> drivers/pci/pci.c| 4
> drivers/pci/quirks.c | 11 ++
On Tue, Jun 30, 2020 at 09:55:54AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > The "ExternalFacing" devices (root ports) are still internal devices that
> > sit on the internal system fabric and thus trusted. Currently they were
> > being marke
On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> The "ExternalFacing" devices (root ports) are still internal devices that
> sit on the internal system fabric and thus trusted. Currently they were
> being marked untrusted.
>
> This patch uses the platform flag to identify the external
Hi Xiang,
On Mon, Jul 06, 2020 at 08:40:27PM +0800, Xiang Zheng wrote:
> > @@ -1836,7 +1880,20 @@ static struct arm_smmu_ctx_desc
> > *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
> >
> > arm_smmu_init_cd(cd);
> >
> > + /*
> > +* Serialize against arm_smmu_domain_finalise_s1() and
On Mon, Jun 29, 2020 at 09:49:37PM -0700, Rajat Jain wrote:
> Currently this is being looked up at a number of places. Read and store it
> once at bootup so that it can be used by all later.
Write the commit log so it is complete even without the subject.
Right now, you have to read the subject to
On 03/07/2020 06:41, Chao Hao wrote:
> The MMU_CTRL register of MT8173 is different from other SoCs.
> The in_order_wr_en is bit[9] which is zero by default.
> Other SoCs have the vitcim_tlb_en feature mapped to bit[12].
> This bit is set to one by default. We need to preserve the bit
> when set
On 03/07/2020 06:41, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
> bit[8
On 03/07/2020 06:41, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN_MASK and F_MMU_STANDARD_AXI_MODE_EN_MASK
> definitions in MISC_CTRL register.
> F_MMU_STANDARD_AXI_MODE_EN_MASK:
> If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow
> standard AXI protocol), the iommu will priori
Hi Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> This patch allows user space to request PASID allocation/free, e.g. when
> serving the request from the guest.
>
> PASIDs that are not freed by userspace are automatically freed when the
> IOASID set is destroyed when process exits.
>
> Cc: Kevin Tian
On 04/07/2020 03:16, Yingjoe Chen wrote:
> On Fri, 2020-07-03 at 12:41 +0800, Chao Hao wrote:
>> Given the fact that we are adding more and more plat_data bool values,
>> it would make sense to use a u32 flags register and add the appropriate
>> macro definitions to set and check for a flag pres
Hi Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> From IOMMU p.o.v., PASIDs allocated and managed by external components
> (e.g. VFIO) will be passed in for gpasid_bind/unbind operation. IOMMU
> needs some knowledge to check the PASID ownership, hence add an interface
> for those components to tell the
Hi Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing
> multiple process virtual address spaces with the device for simplified
> programming model. PASID is used to tag an virtual address space in DMA
> requests and to identify the relat
On Mon, 6 Jul 2020 15:33:58 +0200 Markus Elfring wrote:
>
> I would prefer the following variable declarations then.
>
> + bool kthread, use_mm;
>
>
> > size_t offset;
> >
> > + kthread =3D current->flags & PF_KTHREAD;
> > + use_mm =3D current->mm =3D=3D NULL;
>
> I propose to mov
Hi Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> This patch exports iommu nesting capability info to user space through
> VFIO. User space is expected to check this info for supported uAPIs (e.g.
> PASID alloc/free, bind page table, and cache invalidation) and the vendor
> specific format information fo
…
> +++ b/drivers/vfio/vfio_iommu_type1.c
…
> @@ -2812,11 +2815,10 @@ static int vfio_iommu_type1_dma_rw_chunk
…
> if (!mm)
> return -EPERM;
>
> - if (kthread)
> + if (kthread && use_mm)
Can another design approach make sense here?
+ bool thread_use_mm = ((curren
Hi Yi,
On 7/6/20 3:10 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Auger Eric
>> Sent: Monday, July 6, 2020 6:37 PM
>>
>> Yi,
>>
>> On 7/4/20 1:26 PM, Liu Yi L wrote:
>>> This patch exports iommu nesting capability info to user space through
>>> VFIO. User space is expected to check this info for
Hi Andy,
Sorry for the delay in response. I will do what you suggest in your
email. I do have one response to one of your comments below.
On Thu, Jul 2, 2020 at 4:43 AM Andy Shevchenko
wrote:
>
> On Wed, Jul 01, 2020 at 05:21:38PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in
>> Can it be helpful to convert initialisations for these variables
>> into later assignments?
>
> Perhaps. Then it looks like the below.
…
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -2798,9 +2798,12 @@ static int vfio_iommu_type1_dma_rw_chunk
…
> - bool kthread = current->mm == NULL;
> +
Hi Eric,
> From: Auger Eric
> Sent: Monday, July 6, 2020 9:22 PM
>
> Hi Yi,
>
> On 7/6/20 2:46 PM, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Auger Eric
> >>
> >> Hi Yi,
> >>
> >> Please add a commit message: instead of returning a boolean for
> >> DOMAIN_ATTR_NESTING, arm_smmu_domain_get_at
Hi Yi,
On 7/6/20 2:46 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Auger Eric
>>
>> Hi Yi,
>>
>> Please add a commit message: instead of returning a boolean for
>> DOMAIN_ATTR_NESTING, arm_smmu_domain_get_attr() returns a
>> iommu_nesting_info handle.
>
> will do. thanks for the suggestion.
>
>>
> From: Auger Eric
> Sent: Monday, July 6, 2020 9:01 PM
>
> On 7/6/20 2:20 PM, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Auger Eric
> >> Sent: Monday, July 6, 2020 5:34 PM
> >>
> >> On 7/4/20 1:26 PM, Liu Yi L wrote:
> >>> IOMMUs that support nesting translation needs report the capability
> >
Hi Eric,
> From: Auger Eric
> Sent: Monday, July 6, 2020 6:37 PM
>
> Yi,
>
> On 7/4/20 1:26 PM, Liu Yi L wrote:
> > This patch exports iommu nesting capability info to user space through
> > VFIO. User space is expected to check this info for supported uAPIs (e.g.
> > PASID alloc/free, bind pag
On 7/6/20 2:20 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Auger Eric
>> Sent: Monday, July 6, 2020 5:34 PM
>>
>> On 7/4/20 1:26 PM, Liu Yi L wrote:
>>> IOMMUs that support nesting translation needs report the capability info
>> need to report
>>> to userspace, e.g. the format of first level/st
Hi Eric,
> From: Auger Eric
> Sent: Monday, July 6, 2020 8:56 PM
>
> Hi Yi,
>
> On 7/6/20 2:27 PM, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Auger Eric
> >> Sent: Monday, July 6, 2020 5:34 PM
> >>
> >> Hi Yi,
> >>
> >> On 7/4/20 1:26 PM, Liu Yi L wrote:
> >>> This patch refactors the vfio_i
Hi Yi,
On 7/6/20 2:27 PM, Liu, Yi L wrote:
> Hi Eric,
>
>> From: Auger Eric
>> Sent: Monday, July 6, 2020 5:34 PM
>>
>> Hi Yi,
>>
>> On 7/4/20 1:26 PM, Liu Yi L wrote:
>>> This patch refactors the vfio_iommu_type1_ioctl() to use switch
>>> instead of if-else, and each cmd got a helper function.
Hi Eric,
> From: Auger Eric
>
> Hi Yi,
>
> Please add a commit message: instead of returning a boolean for
> DOMAIN_ATTR_NESTING, arm_smmu_domain_get_attr() returns a
> iommu_nesting_info handle.
will do. thanks for the suggestion.
>
> On 7/4/20 1:26 PM, Liu Yi L wrote:
> > Cc: Will Deacon
On Mon, 6 Jul 2020 13:32:18 +0200 Markus Elfring wrote:
> =E2=80=A6
> > +++ b/drivers/vfio/vfio_iommu_type1.c
> > @@ -2798,7 +2798,8 @@ static int vfio_iommu_type1_dma_rw_chunk
> =E2=80=A6
> > - bool kthread =3D current->mm =3D=3D NULL;
> > + bool kthread =3D current->flags & PF_KTHREAD;
> >
Hi Jean,
On 2020/6/18 23:51, Jean-Philippe Brucker wrote:
> The SMMU has a single ASID space, the union of shared and private ASID
> sets. This means that the SMMU driver competes with the arch allocator
> for ASIDs. Shared ASIDs are those of Linux processes, allocated by the
> arch, and contribut
Hi Eric,
> From: Auger Eric
> Sent: Monday, July 6, 2020 5:34 PM
>
> Hi Yi,
>
> On 7/4/20 1:26 PM, Liu Yi L wrote:
> > This patch refactors the vfio_iommu_type1_ioctl() to use switch
> > instead of if-else, and each cmd got a helper function.
> command
I see. :-)
> >
> > Cc: Kevin Tian
> > C
Hi Eric,
> From: Auger Eric
> Sent: Monday, July 6, 2020 5:34 PM
>
> On 7/4/20 1:26 PM, Liu Yi L wrote:
> > IOMMUs that support nesting translation needs report the capability info
> need to report
> > to userspace, e.g. the format of first level/stage paging structures.
> >
> > This patch repor
…
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -2798,7 +2798,8 @@ static int vfio_iommu_type1_dma_rw_chunk
…
> - bool kthread = current->mm == NULL;
> + bool kthread = current->flags & PF_KTHREAD;
> + bool use_mm = current->mm == NULL;
…
Can it be helpful to convert initialisations for
It's incorrect to tell out if a task is kthread without checking
PF_KTHREAD at all.
What's also fixed, if no need to be in a seperate patch, is to
invoke kthread_use_mm() without checking the current mm first as
the kthread may hold a mm struct atm and it's not the right place
to switch mm.
Fix
Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> This patch exports iommu nesting capability info to user space through
> VFIO. User space is expected to check this info for supported uAPIs (e.g.
> PASID alloc/free, bind page table, and cache invalidation) and the vendor
> specific format information for
Hi Yi,
Please add a commit message: instead of returning a boolean for
DOMAIN_ATTR_NESTING, arm_smmu_domain_get_attr() returns a
iommu_nesting_info handle.
On 7/4/20 1:26 PM, Liu Yi L wrote:
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Suggested-by: Jea
Hi Jacob,
On Thu, Jul 02, 2020 at 06:48:25AM -0700, Jacob Pan wrote:
> Hi Jean,
>
> Just realized I should send this to your Linaro account instead of ARM.
> So Hi again :)
>
> On Wed, 1 Jul 2020 23:29:16 -0700
> Jacob Pan wrote:
>
> > Hi Jean,
> >
> > Have a question for you on whether we ca
Hi Yi,
On 7/4/20 1:26 PM, Liu Yi L wrote:
> This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
> if-else, and each cmd got a helper function.
command
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roed
On 7/4/20 1:26 PM, Liu Yi L wrote:
> IOMMUs that support nesting translation needs report the capability info
need to report
> to userspace, e.g. the format of first level/stage paging structures.
>
> This patch reports nesting info by DOMAIN_ATTR_NESTING. Caller can get
> nesting info after se
+CC Brice.
On Sun, 5 Jul 2020 09:53:58 +
"Song Bao Hua (Barry Song)" wrote:
> > -Original Message-
> > From: Will Deacon [mailto:w...@kernel.org]
> > Sent: Saturday, July 4, 2020 4:22 AM
> > To: Song Bao Hua (Barry Song)
> > Cc: robin.mur...@arm.com; h...@lst.de; m.szyprow...@sa
> It would probably be better to know _which_ context banks we shouldn't
> touch, no? Otherwise what happens to the others?
> Do we not need to worry about the SMRs as well?
This was mimicked from CAF (think [1]) and the SMMUs don't make the
hypervisor angry anymore, so I wouldn't be too picky on
Hi!
> * The first 3 patches tighten the PCI security using ACS, and take care
> of a border case.
> * The 4th patch takes care of PCI bug.
> * 5th and 6th patches expose a device's location into the sysfs to allow
> admin to make decision based on that.
I see no patch for Documentation -- new
Hi Tomasz,
pt., 3 lip 2020 o 11:33 Tomasz Nowicki napisał(a):
>
> On 03.07.2020 11:16, Robin Murphy wrote:
> > On 2020-07-02 21:16, Tomasz Nowicki wrote:
> >> From: Marcin Wojtas
> >>
> >> Add IOMMU node for Marvell AP806 based SoCs together with platform
> >> and PCI device Stream ID mapping.
This adds the downstream property required to support
SMMUs on SDM630 and other platforms (the need for it
most likely depends on firmware configuration).
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 10 ++
drivers/iommu/arm-smmu.c
On 2020/7/6 9:36, Tian, Kevin wrote:
From: Tian, Kevin
Sent: Monday, July 6, 2020 9:30 AM
From: Lu Baolu
Sent: Monday, July 6, 2020 8:26 AM
A pasid might be bound to a page table from a VM guest via the iommu
ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
on the physical
Hi Kevin,
On 2020/7/6 9:29, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, July 6, 2020 8:26 AM
A pasid might be bound to a page table from a VM guest via the iommu
ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
on the physical IOMMU, we need to inject the page fault req
88 matches
Mail list logo
