All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Alex Williamson
	<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org,
	kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org
Subject: Re: [PATCH v5 0/4] vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1
Date: Fri, 06 Mar 2015 10:04:22 +0100	[thread overview]
Message-ID: <54F96D96.8040207@linaro.org> (raw)
In-Reply-To: <1425589915.5200.336.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On 03/05/2015 10:11 PM, Alex Williamson wrote:
> On Thu, 2015-03-05 at 18:34 +0100, Eric Auger wrote:
>> Hi All,
>>
>> Ironically, since the correction of the IOMMU_CAP_CACHE_COHERENCY bug
>> (https://lkml.org/lkml/2015/1/29/514) in vfio_iommu_type1.c, my Calxeda
>> Midway VFIO use case is not working anymore. This is also observable
>> when I do not apply at all the whole [PATCH v5 0/4] vfio: type1: support
>> for ARM SMMUS with VFIO_IOMMU_TYPE1 series.
>>
>> My understanding is this series should not be requested for me since my
>> xgmac device does not care about the XN attribute.
> 
> This also raises the concern that we're continuing to put optional
> features as prerequisites to base vfio-platform support and creating
> self-induced stalls at getting anything upstream :-\  Thanks,
Dear all,

Thanks Alex, Will for your inputs on this topic.

Yes to me "vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1" is
not a direct dependency of vfio-platform driver although I understand
Baptiste needs it to test with PL330 device. On my side I can test
vfio-platform driver without it, assigning the Midway Calxeda xgmac.

Also if I am not wrong the title of the series now does not really
reflect anymore what the series aims at. since "[PATCH v3 2/6] vfio:
type1: support for ARM SMMUs"  withdrawal, the series now "only" aims at
supporting the VFIO_DMA_MAP_FLAG_NOEXEC flag.

However with this issue of IOMMU_CACHE always set along with arm-smmu,
there is a need for an adaptation of either vfio_iommu_type1 or arm-smmu
since the integrated pieces are not functional.

On top of the dma-coherent property of the *master*, should not we also
query the cache-coherent property of the interconnect downstream to the
smmu?

How can we progress quickly on this topic? is it acceptable to return
false on arm_smmu_capable(IOMMU_CAP_CACHE_COHERENCY) as a quick hack? As
a longer term solution, would it make sense to add a user flag at VFIO
user API level to turn the IOMMU_CACHE on?

Best Regards

Eric


Best Regards

Eric

Best Regards

Eric
> 
> Alex
> 

  parent reply	other threads:[~2015-03-06  9:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 16:07 [PATCH v5 0/4] vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1 Baptiste Reynal
2015-03-04 16:07 ` [PATCH v5 1/4] vfio: implement iommu driver capabilities with an enum Baptiste Reynal
2015-03-04 16:07   ` Baptiste Reynal
2015-03-04 16:07 ` [PATCH v5 2/4] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag Baptiste Reynal
2015-03-04 16:07   ` Baptiste Reynal
2015-03-04 16:07 ` [PATCH v5 3/4] vfio: type1: replace vfio_domains_have_iommu_cache with generic function Baptiste Reynal
2015-03-04 16:07   ` Baptiste Reynal
2015-03-04 16:07 ` [PATCH v5 4/4] vfio: type1: implement the VFIO_DMA_MAP_FLAG_NOEXEC flag Baptiste Reynal
2015-03-04 16:07   ` Baptiste Reynal
     [not found] ` <1425485274-5709-1-git-send-email-b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-03-04 17:45   ` [PATCH v5 0/4] vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1 Alex Williamson
2015-03-05 10:16     ` Baptiste Reynal
     [not found]     ` <1425491104.5200.268.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-05 17:34       ` Eric Auger
     [not found]         ` <54F893C3.6020006-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-03-05 17:54           ` Alex Williamson
     [not found]             ` <1425578066.5200.331.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-05 18:09               ` Will Deacon
2015-03-05 21:11           ` Alex Williamson
     [not found]             ` <1425589915.5200.336.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-06  9:04               ` Eric Auger [this message]
     [not found]                 ` <54F96D96.8040207-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-03-06 10:41                   ` Will Deacon
     [not found]                     ` <20150306104148.GC22377-5wv7dgnIgG8@public.gmane.org>
2015-03-06 11:27                       ` Baptiste Reynal
     [not found]                         ` <CAN9JPjHWcXuzkByJY1gnbvi28nZX8RBbZXDA2t-VeK6v8OrSRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-06 12:41                           ` Eric Auger
2015-03-06 13:17                           ` Eric Auger
     [not found]                             ` <54F9A8EE.9020008-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-03-06 13:44                               ` Baptiste Reynal
2015-03-06 14:46                     ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F96D96.8040207@linaro.org \
    --to=eric.auger-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
    --cc=tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.