All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Alex Williamson
	<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	iommu
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [RFC] Independent use of IOMMU groups
Date: Fri, 27 Nov 2015 16:39:10 +0100	[thread overview]
Message-ID: <20151127153910.GL2064@8bytes.org> (raw)
In-Reply-To: <1446824140.8831.168.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi Alex,

On Fri, Nov 06, 2015 at 08:35:40AM -0700, Alex Williamson wrote:
> VFIO is really built on iommu groups, so making a vfio group independent
> of iommu groups is a difficult proposition.

I have been thinking about the relation between vfio device groups and
iommu-groups lately, because at least for PCI the iommu-grouping is too
coarse grained. I ran into this with the default-domain approach I am
working on.

Grouping devices together that have different request-ids (multifunction
and acs based grouping) only makes sense when the device is controlled
by an untrusted piece of software, in our case userspace or a KVM guest.
The device drivers in Linux are trusted, and this coarse grained
grouping becomes problematic, because it forces more devices into a
single domain, which can become a bottleneck for DMA-API allocations.

I have been thinking about moving the multi-function and acs grouping
into vfio code, meaning that a vfio-group contains more than one
iommu-group. The problem with this is that iommu-groups are exposed
in sysfs and thus became a userspace ABI.

So the vfio-group code might need changes anyway which could solve the
above problem too, no? I am just not sure yet what the best way is to
solve it.


	Joerg

  parent reply	other threads:[~2015-11-27 15:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05 17:54 [RFC] Independent use of IOMMU groups Alex Williamson
     [not found] ` <1446746079.8831.82.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-11-06 12:29   ` Joerg Roedel
     [not found]     ` <20151106122939.GA13027-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-11-06 15:35       ` Alex Williamson
     [not found]         ` <1446824140.8831.168.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-11-27 15:39           ` Joerg Roedel [this message]
     [not found]             ` <20151127153910.GL2064-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-12-02 15:58               ` 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=20151127153910.GL2064@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=pbonzini-H+wXaHxf7aLQT0dZR+AlfA@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.