qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Stuart Yoder <b08248@gmail.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"agraf@suse.de" <agraf@suse.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Yoder Stuart-B08248 <B08248@freescale.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Bhushan Bharat-R65777 <R65777@freescale.com>,
	Scott Wood <scottwood@freescale.com>
Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc
Date: Tue, 02 Apr 2013 15:38:45 -0600	[thread overview]
Message-ID: <1364938725.2882.184.camel@bling.home> (raw)
In-Reply-To: <CALRxmdCe-RMZuhPSviQsQUxWZbxXABOZDsM8ZoNaqrp=xH+TaA@mail.gmail.com>

On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
> On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood <scottwood@freescale.com> wrote:
> >> >    C.  Explicit mapping using normal DMA map.  The last idea is that
> >> >        we would introduce a new ioctl to give user-space an fd to
> >> >        the MSI bank, which could be mmapped.  The flow would be
> >> >        something like this:
> >> >           -for each group user space calls new ioctl
> >> > VFIO_GROUP_GET_MSI_FD
> >> >           -user space mmaps the fd, getting a vaddr
> >> >           -user space does a normal DMA map for desired iova
> >> >        This approach makes everything explicit, but adds a new ioctl
> >> >        applicable most likely only to the PAMU (type2 iommu).
> >>
> >> And the DMA_MAP of that mmap then allows userspace to select the window
> >> used?  This one seems like a lot of overhead, adding a new ioctl, new
> >> fd, mmap, special mapping path, etc.
> >
> >
> > There's going to be special stuff no matter what.  This would keep it
> > separated from the IOMMU map code.
> >
> > I'm not sure what you mean by "overhead" here... the runtime overhead of
> > setting things up is not particularly relevant as long as it's reasonable.
> > If you mean development and maintenance effort, keeping things well
> > separated should help.
> 
> We don't need to change DMA_MAP.  If we can simply add a new "type 2"
> ioctl that allows user space to set which windows are MSIs, it seems vastly
> less complex than an ioctl to supply a new fd, mmap of it, etc.
> 
> So maybe 2 ioctls:
>     VFIO_IOMMU_GET_MSI_COUNT
>     VFIO_IOMMU_MAP_MSI(iova, size)
> 

How are MSIs related to devices on PAMU?  On x86 MSI count is very
device specific, which means it wold be a VFIO_DEVICE_* ioctl (actually
VFIO_DEVICE_GET_IRQ_INFO does this for us on x86).  The trouble with it
being a device ioctl is that you need to get the device FD, but the
IOMMU protection needs to be established before you can get that... so
there's an ordering problem if you need it from the device before
configuring the IOMMU.  Thanks,

Alex

  reply	other threads:[~2013-04-02 21:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 17:32 [Qemu-devel] RFC: vfio API changes needed for powerpc Yoder Stuart-B08248
2013-04-02 19:39 ` Scott Wood
2013-04-02 20:38   ` Stuart Yoder
2013-04-02 20:47     ` Scott Wood
2013-04-02 20:58       ` Stuart Yoder
2013-04-02 20:32 ` Alex Williamson
2013-04-02 20:54   ` Stuart Yoder
2013-04-02 21:16     ` Alex Williamson
2013-04-02 22:13       ` Scott Wood
2013-04-03  2:54         ` Alex Williamson
2013-04-02 20:57   ` Scott Wood
2013-04-02 21:08     ` Stuart Yoder
2013-04-02 21:38       ` Alex Williamson [this message]
2013-04-02 22:50         ` Scott Wood
2013-04-03  3:37           ` Alex Williamson
2013-04-03 19:09             ` Stuart Yoder
2013-04-03 19:18               ` Scott Wood
2013-04-03 19:43                 ` Stuart Yoder
2013-04-03 20:00                   ` Scott Wood
2013-04-03 19:23               ` Alex Williamson
2013-04-03 19:26               ` Scott Wood
2013-04-03 21:19             ` Scott Wood
2013-04-03 18:32           ` Stuart Yoder
2013-04-03 18:39             ` Scott Wood
2013-04-02 21:55       ` Scott Wood
2013-04-02 21:32     ` Alex Williamson
2013-04-02 22:44       ` Scott Wood
2013-04-03  3:12         ` Alex Williamson
2013-04-03 18:25           ` Stuart Yoder
2013-04-03 21:25           ` Scott Wood

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=1364938725.2882.184.camel@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=B07421@freescale.com \
    --cc=B08248@freescale.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=b08248@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=scottwood@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).