From: Anup Patel <anup.patel@broadcom.com>
To: Will Deacon <will.deacon@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
Baptiste Reynal <b.reynal@virtualopensystems.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: Scott Branden <sbranden@broadcom.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org, kvm@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
Anup Patel <anup.patel@broadcom.com>
Subject: [PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present()
Date: Thu, 20 Jul 2017 10:02:33 +0530 [thread overview]
Message-ID: <1500525154-5200-2-git-send-email-anup.patel@broadcom.com> (raw)
In-Reply-To: <1500525154-5200-1-git-send-email-anup.patel@broadcom.com>
Not allowing No-IOMMU mode for devices already having
iommu_ops on their bus is very conservative.
We now have IOMMU (such as ARM SMMU) which can bypass
transcations when IOMMU is not configured for a given
device. In addition, it is not necessary to have all
devices on bus to be upstream to an IOMMU on that bus.
Due above reasons, having iommu_present() check for
VFIO No-IOMMU mode is not appropriate.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
---
drivers/vfio/vfio.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 330d505..9d90de7 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -124,11 +124,10 @@ struct iommu_group *vfio_iommu_group_get(struct device *dev)
#ifdef CONFIG_VFIO_NOIOMMU
/*
* With noiommu enabled, an IOMMU group will be created for a device
- * that doesn't already have one and doesn't have an iommu_ops on their
- * bus. We set iommudata simply to be able to identify these groups
- * as special use and for reclamation later.
+ * that doesn't already have one. We set iommudata simply to be able
+ * to identify these groups as special use and for reclamation later.
*/
- if (group || !noiommu || iommu_present(dev->bus))
+ if (group || !noiommu)
return group;
group = iommu_group_alloc();
--
2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Anup Patel via iommu <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
Baptiste Reynal
<b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Scott Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: [PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present()
Date: Thu, 20 Jul 2017 10:02:33 +0530 [thread overview]
Message-ID: <1500525154-5200-2-git-send-email-anup.patel@broadcom.com> (raw)
In-Reply-To: <1500525154-5200-1-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Not allowing No-IOMMU mode for devices already having
iommu_ops on their bus is very conservative.
We now have IOMMU (such as ARM SMMU) which can bypass
transcations when IOMMU is not configured for a given
device. In addition, it is not necessary to have all
devices on bus to be upstream to an IOMMU on that bus.
Due above reasons, having iommu_present() check for
VFIO No-IOMMU mode is not appropriate.
Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/vfio/vfio.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 330d505..9d90de7 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -124,11 +124,10 @@ struct iommu_group *vfio_iommu_group_get(struct device *dev)
#ifdef CONFIG_VFIO_NOIOMMU
/*
* With noiommu enabled, an IOMMU group will be created for a device
- * that doesn't already have one and doesn't have an iommu_ops on their
- * bus. We set iommudata simply to be able to identify these groups
- * as special use and for reclamation later.
+ * that doesn't already have one. We set iommudata simply to be able
+ * to identify these groups as special use and for reclamation later.
*/
- if (group || !noiommu || iommu_present(dev->bus))
+ if (group || !noiommu)
return group;
group = iommu_group_alloc();
--
2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: anup.patel@broadcom.com (Anup Patel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present()
Date: Thu, 20 Jul 2017 10:02:33 +0530 [thread overview]
Message-ID: <1500525154-5200-2-git-send-email-anup.patel@broadcom.com> (raw)
In-Reply-To: <1500525154-5200-1-git-send-email-anup.patel@broadcom.com>
Not allowing No-IOMMU mode for devices already having
iommu_ops on their bus is very conservative.
We now have IOMMU (such as ARM SMMU) which can bypass
transcations when IOMMU is not configured for a given
device. In addition, it is not necessary to have all
devices on bus to be upstream to an IOMMU on that bus.
Due above reasons, having iommu_present() check for
VFIO No-IOMMU mode is not appropriate.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
---
drivers/vfio/vfio.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 330d505..9d90de7 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -124,11 +124,10 @@ struct iommu_group *vfio_iommu_group_get(struct device *dev)
#ifdef CONFIG_VFIO_NOIOMMU
/*
* With noiommu enabled, an IOMMU group will be created for a device
- * that doesn't already have one and doesn't have an iommu_ops on their
- * bus. We set iommudata simply to be able to identify these groups
- * as special use and for reclamation later.
+ * that doesn't already have one. We set iommudata simply to be able
+ * to identify these groups as special use and for reclamation later.
*/
- if (group || !noiommu || iommu_present(dev->bus))
+ if (group || !noiommu)
return group;
group = iommu_group_alloc();
--
2.7.4
next prev parent reply other threads:[~2017-07-20 4:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 4:32 [PATCH v2 0/2] FlexRM support in VFIO platform Anup Patel
2017-07-20 4:32 ` Anup Patel
2017-07-20 4:32 ` Anup Patel [this message]
2017-07-20 4:32 ` [PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present() Anup Patel
2017-07-20 4:32 ` Anup Patel via iommu
2017-07-20 9:19 ` Will Deacon
2017-07-20 9:19 ` Will Deacon
2017-07-24 17:24 ` Alex Williamson
2017-07-24 17:24 ` Alex Williamson
2017-07-24 17:24 ` Alex Williamson
2017-07-20 4:32 ` [PATCH v2 2/2] vfio: platform: reset: Add Broadcom FlexRM reset module Anup Patel
2017-07-20 4:32 ` Anup Patel
2017-07-20 4:32 ` Anup Patel via iommu
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=1500525154-5200-2-git-send-email-anup.patel@broadcom.com \
--to=anup.patel@broadcom.com \
--cc=alex.williamson@redhat.com \
--cc=b.reynal@virtualopensystems.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=sbranden@broadcom.com \
--cc=will.deacon@arm.com \
/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.