On Tue, Jun 18, 2019 at 01:08:06AM +0200, Thomas Gleixner wrote:
> Stephane,
>
> On Mon, 17 Jun 2019, Stephane Eranian wrote:
> > On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner wrote:
> > > Great that there is no trace of any mail from Andi or Stephane about this
> > > on LKML. There is no
Hi Tony,
On 8/26/19 7:14 PM, Suman Anna wrote:
> Hi Tony,
>
> The following 2 patches need to go along with the recent "iommu/omap: misc
> fixes" series [1] that is currently staged [2] for a 5.4 merge and available
> in linux-next. That series added runtime pm callbacks in preparation for
> the
From: Boqun Feng Sent: Wednesday, October 16, 2019 5:57
PM
>
> Currently hyperv-iommu is implemented in a x86 specific way, for
> example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86
> as a preparation for enabling HyperV on architecture other than x86.
>
> Cc: Lan Tianyu
>
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory map to OS, including OS usable
memory ranges and BIOS reserved memory ranges etc.
x86 BIOS may not be trusted to
On Wed, Oct 16, 2019 at 06:07:36PM +0100, Robin Murphy wrote:
> @@ -1180,7 +1179,7 @@ int iommu_dma_prepare_msi(struct msi_desc *desc,
> phys_addr_t msi_addr)
> struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> struct iommu_dma_cookie *cookie;
> struct
On Thu, Oct 17, 2019 at 09:08:47AM +0200, Christoph Hellwig wrote:
> On Wed, Oct 16, 2019 at 03:15:52PM -0400, Arvind Sankar wrote:
> > > > Reported-by: Arvind Sankar
> > > > Tested-by: Arvind Sankar
> > > > Originally-by: Christoph Hellwig
> > > > Signed-off-by: Christoph Hellwig
> > > >
On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > BTW, the previous x86 warning was from only reverted one patch "iommu: Add
> > gfp
> > parameter to iommu_ops::map" where proved to be insufficient. Now, pasting
> > the
> >
> On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote:
>
> I guess the mode level 6 check is really for other potential callers
> increase_address_space, none exist at the moment, and the condition
> of the while loop in alloc_pte should fail if the mode level is 6.
Because there is no
On 10/17/19 12:16 PM, Vladimir Murzin wrote:
On 10/17/19 11:03 AM, Alexandre Torgue wrote:
Hi Vlad
On 10/17/19 11:46 AM, Vladimir Murzin wrote:
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
Hi,
It
Hi Vlad
On 10/17/19 11:46 AM, Vladimir Murzin wrote:
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
Hi,
It looks like dma_alloc_coherent() is setting the dma_handle output
parameter to the memory
On 10/17/19 11:03 AM, Alexandre Torgue wrote:
> Hi Vlad
>
> On 10/17/19 11:46 AM, Vladimir Murzin wrote:
>> On 10/14/19 4:01 PM, Vladimir Murzin wrote:
>>> On 10/14/19 2:54 PM, Robin Murphy wrote:
On 13/10/2019 15:28, Daniele Alessandrelli wrote:
> Hi,
>
> It looks like
On 10/14/19 4:01 PM, Vladimir Murzin wrote:
> On 10/14/19 2:54 PM, Robin Murphy wrote:
>> On 13/10/2019 15:28, Daniele Alessandrelli wrote:
>>> Hi,
>>>
>>> It looks like dma_alloc_coherent() is setting the dma_handle output
>>> parameter to the memory physical address and not the device bus
>>>
12 matches
Mail list logo
