On 2019/2/26 20:36, Hanjun Guo wrote:
> Hi Jean,
>
> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 31/01/2019 13:52, Zhen Lei wrote:
>>> Currently, many peripherals are faster than before. For example, the top
>>> speed of the older netcard is 10Gb/s, and now it's more than 2
Otherwise, the translation type field of a context entry for
a PCI device will always be 0. All translated DMA requests
will be blocked by IOMMU. As the result, the PCI devices with
PCI ATS (device IOTBL) support won't work as expected.
Cc: Ashok Raj
Cc: Jacob Pan
Suggested-by: Kevin Tian
Fixes
Intel IOMMU could be turned off with intel_iommu=off. If Intel
IOMMU is off, the intel_iommu struct will not be initialized.
When device drivers call intel_svm_bind_mm(), the NULL pointer
reference will happen there.
Add dmar_disabled check to avoid NULL pointer reference.
Cc: Ashok Raj
Cc: Jac
After tearing down a pasid entry, the domain id is used to
invalidate the translation caches. Retrieve the domain id
from the pasid entry value before clearing the pasid entry.
Otherwise, we will always use domain id 0.
Cc: Ashok Raj
Cc: Jacob Pan
Signed-off-by: Liu Yi L
Fixes: 6f7db75e1c469 ("
Hi Joerg,
This includes several small fixes. All are stable kernel irrelated.
Please consider it for 5.1-rc1.
Best regards,
Lu Baolu
Lu Baolu (4):
iommu/vt-d: Disable ATS support on untrusted devices
iommu/vt-d: Set context field after value initialized
iommu/vt-d: Fix NULL pointer referen
Commit fb58fdcd295b9 ("iommu/vt-d: Do not enable ATS for untrusted
devices") disables ATS support on the devices which have been marked
as untrusted. Unfortunately this is not enough to fix the DMA attack
vulnerabiltiies because IOMMU driver allows translated requests as
long as a device advertises
On Fri, Mar 1, 2019 at 11:04 AM Pingfan Liu wrote:
>
> Hi Borislav,
>
> Do you think the following patch is good at present?
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 81f9d23..9213073 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -460,7
Hi Borislav,
Do you think the following patch is good at present?
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 81f9d23..9213073 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -460,7 +460,7 @@ static void __init
memblock_x86_reserve_range_setup_data(vo
On Thu, Feb 28, 2019 at 01:15:49PM -0800, Jacob Pan wrote:
> On Thu, 28 Feb 2019 15:09:50 +0100
> Joerg Roedel wrote:
>
> > Hi Jacob,
> >
> > On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote:
> > > On Tue, 26 Feb 2019 12:17:43 +0100
> > > Joerg Roedel wrote:
> >
> > > Just trying to
On Thu, 28 Feb 2019 15:09:50 +0100
Joerg Roedel wrote:
> Hi Jacob,
>
> On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote:
> > On Tue, 26 Feb 2019 12:17:43 +0100
> > Joerg Roedel wrote:
>
> > Just trying to understand how to use this API.
> > So if we bind the same mm to two different
On Thu, 28 Feb 2019 01:10:55 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Thursday, February 28, 2019 5:41 AM
> >
> > On Tue, 26 Feb 2019 12:17:43 +0100
> > Joerg Roedel wrote:
> >
> > >
> > > How about a 'struct iommu_sva' with an iommu-pri
On Thu, 28 Feb 2019 12:19:22 +
Jean-Philippe Brucker wrote:
> On 27/02/2019 21:41, Jacob Pan wrote:
> > On Tue, 26 Feb 2019 12:17:43 +0100
> > Joerg Roedel wrote:
> >
> >> Hi Jean-Philippe,
> >>
> >> Thanks for the patch! I think this is getting close to be applied
> >> after the next mer
Hi Jacob,
On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote:
> On Tue, 26 Feb 2019 12:17:43 +0100
> Joerg Roedel wrote:
> Just trying to understand how to use this API.
> So if we bind the same mm to two different devices, we should get two
> different iommu_sva handle, right?
> I think
On Thu, Feb 28, 2019 at 01:19:48PM +0100, Stanislaw Gruszka wrote:
> Nevermind, the patch is wrong, s->dma_address is initalized in sg_num_pages().
Yes, it is. In sg_num_pages() the offset into the IOMMU mapping is
stored in s->dma_address, taking also the segment boundary mask into
account. map_s
On 27/02/2019 21:41, Jacob Pan wrote:
> On Tue, 26 Feb 2019 12:17:43 +0100
> Joerg Roedel wrote:
>
>> Hi Jean-Philippe,
>>
>> Thanks for the patch! I think this is getting close to be applied
>> after the next merge window.
>>
>> On Wed, Feb 20, 2019 at 02:27:59PM +, Jean-Philippe Brucker wro
On Thu, Feb 28, 2019 at 11:42:24AM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> > > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > > > On Tue, Feb 26,
On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > > > On Tue, Feb 26,
On Wed, Feb 27, 2019 at 10:54:02PM +0800, lantianyu1...@gmail.com wrote:
> Lan Tianyu (3):
> x86/Hyper-V: Set x2apic destination mode to physical when x2apic is
> available
> HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
> MAINTAINERS: Add Hyper-V IOMMU driver into Hyper-V CORE AND DRIV
On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > > On Tue, Feb 26, 2019 at 11:05:36AM +0100, Joerg Roedel wrote:
> > > If sg->offset > PAGE_SI
19 matches
Mail list logo
