> From: Liu, Yi L
> Sent: Monday, July 3, 2017 6:31 PM
>
> Hi Jean,
>
>
> >
> > > 2. Define a structure in include/uapi/linux/iommu.h(newly added header
> file)
> > >
> > > struct iommu_tlb_invalidate {
> > > __u32 scope;
> > > /* pasid-selective invalidation described by @pasid */
> > > #de
> From: Liu, Yi L [mailto:yi.l@linux.intel.com]
> Sent: Sunday, May 14, 2017 6:55 PM
>
> On Fri, May 12, 2017 at 03:58:43PM -0600, Alex Williamson wrote:
> > On Wed, 26 Apr 2017 18:12:04 +0800
> > "Liu, Yi L" wrote:
> >
> > > From: "Liu, Yi L"
> > >
> > > This patch adds VFIO_IOMMU_TLB_INVAL
Hi Will/Robin,
Has anything functionally changed between PATCH v2 and v1? I'm seeing a
very different L2 throughput with v2 (in general a lot worse with v2 vs.
v1); however, I'm currently unable to reproduce the TLB sync timed out
issue with v2 (without the patch from Will's email).
It could also
Hi Will,
On 7/4/17 10:31 AM, Will Deacon wrote:
> Ray,
>
> On Wed, Jun 28, 2017 at 10:02:35AM -0700, Ray Jui wrote:
>> On 6/28/17 4:46 AM, Will Deacon wrote:
>>> Robin and I have been bashing our heads against the tlb_sync_pending flag
>>> this morning, and we reckon it could have something to do
On Fri, Jun 23, 2017 at 03:58:01PM +0100, shameer wrote:
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
>
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the
Ray,
On Wed, Jun 28, 2017 at 10:02:35AM -0700, Ray Jui wrote:
> On 6/28/17 4:46 AM, Will Deacon wrote:
> > Robin and I have been bashing our heads against the tlb_sync_pending flag
> > this morning, and we reckon it could have something to do with your timeouts
> > on MMU-500.
> >
> > On Tue, Jun
Just to be clear which patch should I test and would you provide me with
the link of its location?
Thanks,
Craig
On Jun 28, 2017 16:14, "Deucher, Alexander"
wrote:
> > -Original Message-
> > From: Joerg Roedel [mailto:j...@8bytes.org]
> > Sent: Wednesday, June 28, 2017 4:37 AM
> > To: J
Current implementation of __iommu_dma_alloc_pages() keeps adding
__GFP_HIGHMEM to GFP flags regardless of whether other zone flags are
already included in the incoming flags. If __GFP_DMA or __GFP_DMA32 is
set at the same time as __GFP_HIGHMEM, the allocation fails due to
invalid zone flag combinat
Memory allocation routines are expected to report allocation errors to
kernel log. However, current implementation of __iommu_dma_alloc_pages()
adds __GFP_NOWARN for all calls to alloc_pages(), which completely
disables any logging.
Fix it by adding __GFP_NOWARN only to high order allocation attem
Hi Jean,
On Mon, Jul 03, 2017 at 12:52:52PM +0100, Jean-Philippe Brucker wrote:
> Hi Yi,
>
> On 02/07/17 11:06, Liu, Yi L wrote:
> > On Fri, May 12, 2017 at 01:11:02PM +0100, Jean-Philippe Brucker wrote:
> >
> > Hi Jean,
> >
> > As we've got a few discussions on it. I'd like to have a conclusio
On Mon, Jul 03, 2017 at 08:18:45AM +, Shameerali Kolothum Thodi wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: Friday, June 23, 2017 5:54 PM
> > To: Shameerali Kolothum Thodi
> > Cc: marc.zyng...@arm.com; sudeep.ho...@arm.com
Hi Robert,
On Wed, Jun 28, 2017 at 07:47:50PM +0200, Robert Richter wrote:
> On 15.06.17 14:46:03, Lorenzo Pieralisi wrote:
> > On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote:
> > > Add code to parse proximity domain in SMMUv3 IORT table to
> > > set numa node mapping for smmu
12 matches
Mail list logo
