Hi Eric,
On 2021/2/12 16:55, Auger Eric wrote:
> Hi Keqian,
>
> On 2/1/21 12:52 PM, Keqian Zhu wrote:
>> Hi Eric,
>>
>> On 2020/11/18 19:21, Eric Auger wrote:
>>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>>> for each MSI doorbell. If both the host and the guest are exposed
Reviewed-by: Huacai Chen
On Wed, Feb 10, 2021 at 6:04 PM Christoph Hellwig wrote:
>
> CONFIG_DMA_MAYBE_COHERENT just guards two early init options now. Just
> enable them unconditionally for CONFIG_DMA_NONCOHERENT.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/Kconfig| 8
Hi Keqian,
On 2/18/21 9:43 AM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2021/2/12 16:55, Auger Eric wrote:
>> Hi Keqian,
>>
>> On 2/1/21 12:52 PM, Keqian Zhu wrote:
>>> Hi Eric,
>>>
>>> On 2020/11/18 19:21, Eric Auger wrote:
On ARM, MSI are translated by the SMMU. An IOVA is allocated
for
Hi Guillaume,
Thank you for the test results! And sorry for my belated reply.
On Thu, Feb 11, 2021 at 03:50:05PM +, Guillaume Tucker wrote:
> > On Sat, Feb 06, 2021 at 01:40:13PM +, Guillaume Tucker wrote:
> >>> It'd be nicer if I can get both logs of the vanilla kernel (failing)
> >>>
Hi Eric,
> > -Original Message-
> > From: Eric Auger [mailto:eric.au...@redhat.com]
> > Sent: 16 November 2020 11:00
> > To: eric.auger@gmail.com; eric.au...@redhat.com;
> > iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> > k...@vger.kernel.org;
Hi Shameer,
On 2/18/21 11:36 AM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>>> -Original Message-
>>> From: Eric Auger [mailto:eric.au...@redhat.com]
>>> Sent: 16 November 2020 11:00
>>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>>> iommu@lists.linux-foundation.org;
el it safer to revert my
> previous change, not necessarily being a complete revert though.
>
> I attached my partial reverting change in this email. Would it be
> possible for you to run one more test for me to confirm it? It'd
> keep the tests passing while eliminating all error pr
Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and
tegra_smmu_configure() that are typically done in the IOMMU core also.
Write protect bit, when set, inhibits supervisor writes to the read-only
pages. In supervisor shared virtual addressing (SVA), where page tables
are shared between CPU and DMA, IOMMU PASID entry WPE bit should match
CR0.WP bit in the CPU.
This patch sets WPE bit for supervisor PASIDs if CR0.WP is
Page requests are originated from the user page fault. Therefore, we
shall set FAULT_FLAG_USER.
FAULT_FLAG_REMOTE indicates that we are walking an mm which is not
guaranteed to be the same as the current->mm and should not be subject
to protection key enforcement. Therefore, we should set
When supervisor/privilige mode SVM is used, we bind init_mm.pgd with
a supervisor PASID. There should not be any page fault for init_mm.
Execution request with DMA read is also not supported.
This patch checks PRQ descriptor for both unsupported configurations,
reject them both with invalid
Write protect bit, when set, inhibits supervisor writes to the read-only
pages. In guest supervisor shared virtual addressing (SVA), write-protect
should be honored upon guest bind supervisor PASID request.
This patch extends the VT-d portion of the IOMMU UAPI to include WP bit.
WPE bit of the
Hi Baolu et al,
This is a collection of SVA-related fixes.
Thanks,
Jacob
Jacob Pan (4):
iommu/vt-d: Enable write protect for supervisor SVM
iommu/vt-d: Enable write protect propagation from guest
iommu/vt-d: Reject unsupported page request modes
iommu/vt-d: Calculate and set flags for
> From: Jacob Pan
> Sent: Friday, February 19, 2021 5:31 AM
>
> Write protect bit, when set, inhibits supervisor writes to the read-only
> pages. In guest supervisor shared virtual addressing (SVA), write-protect
> should be honored upon guest bind supervisor PASID request.
>
> This patch
On 17 Feb 2021 10:37, Jean-Philippe Brucker wrote:
> On Tue, Feb 16, 2021 at 02:31:03PM -0700, Al Stone wrote:
> > Would you believe last week's meeting was canceled, too? Not sure
> > why the chair/co-chair are doing this but I'm finding it a little
> > frustrating.
> >
> > We'll try again this
15 matches
Mail list logo