From: "Michael S. Tsirkin" <mst@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Avi Kivity <avi@redhat.com>, Tom Lyon <pugs@cisco.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
chrisw@sous-sol.org, hjk@linutronix.de, gregkh@suse.de,
aafabbri@cisco.com, scofeldm@cisco.com
Subject: Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers
Date: Wed, 2 Jun 2010 14:21:00 +0300 [thread overview]
Message-ID: <20100602112100.GA29697@redhat.com> (raw)
In-Reply-To: <20100602111224.GA11033@8bytes.org>
On Wed, Jun 02, 2010 at 01:12:25PM +0200, Joerg Roedel wrote:
> On Wed, Jun 02, 2010 at 01:38:28PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 02, 2010 at 12:35:16PM +0200, Joerg Roedel wrote:
>
> > > With the userspace interface a process can create io-page-faults
> > > anyway if it wants. We can't protect us from this.
> >
> > We could fail all operations until an iommu is bound. This will help
> > catch bugs with access before setup. We can not do this if a domain is
> > bound by default.
>
> Even if it is bound to a domain the userspace driver could program the
> device to do dma to unmapped regions causing io-page-faults. The kernel
> can't do anything about it.
It can always corrupt its own memory directly as well :)
But that is not a reason not to detect errors if we can,
and not to make APIs hard to misuse.
> > > The second IOMMU_MAP ioctl is just to show that existing mappings would
> > > be destroyed if the device is assigned to another address space. Not
> > > strictly necessary. So we have two ioctls but save one call to create
> > > the iommu-domain.
> >
> > With 10 devices you have 10 extra ioctls.
>
> And this works implicitly with your proposal?
Yes. so you do:
iommu = open
ioctl(dev1, BIND, iommu)
ioctl(dev2, BIND, iommu)
ioctl(dev3, BIND, iommu)
ioctl(dev4, BIND, iommu)
No need to add a SHARE ioctl.
> Remember that we still
> need to be able to provide seperate mappings for each device to support
> IOMMU emulation for the guest.
Generally not true. E.g. guest can enable iommu passthrough
or have domain per a group of devices.
> I think my proposal does not have any
> extra costs.
with my proposal we have 1 ioctl per device + 1 per domain.
with yours we have 2 ioctls per device is iommu is shared
and 1 if it is not shared.
as current apps share iommu it seems to make sense
to optimize for that.
> > > Because we express here that "dev2 shares the iommu mappings of dev1".
> > > Thats easy to remember.
> >
> > they both share the mappings. which one gets the iommu
> > destroyed (breaking the device if it is now doing DMA)?
>
> As I wrote the domain has a reference count and is destroyed only when
> it goes down to zero. This does not happen as long as a device is bound
> to it.
>
> Joerg
We were talking about UNSHARE ioctl:
ioctl(dev1, UNSHARE, dev2)
Does it change the domain for dev1 or dev2?
If you make a mistake you get a hard to debug bug.
--
MST
next prev parent reply other threads:[~2010-06-02 11:25 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-28 23:07 [PATCH] VFIO driver: Non-privileged user level PCI drivers Tom Lyon
2010-05-28 23:36 ` Randy Dunlap
2010-05-28 23:56 ` Randy Dunlap
2010-05-29 11:55 ` Arnd Bergmann
2010-05-29 12:16 ` Avi Kivity
2010-05-30 12:19 ` Michael S. Tsirkin
2010-05-30 12:27 ` Avi Kivity
2010-05-30 12:49 ` Michael S. Tsirkin
2010-05-30 13:01 ` Avi Kivity
2010-05-30 13:03 ` Michael S. Tsirkin
2010-05-30 13:13 ` Avi Kivity
2010-05-30 14:53 ` Michael S. Tsirkin
2010-05-31 11:50 ` Avi Kivity
2010-05-31 17:10 ` Michael S. Tsirkin
2010-06-01 8:10 ` Avi Kivity
2010-06-01 9:55 ` Michael S. Tsirkin
2010-06-01 10:28 ` Avi Kivity
2010-06-01 10:46 ` Michael S. Tsirkin
2010-06-01 12:41 ` Avi Kivity
2010-06-02 9:45 ` Joerg Roedel
2010-06-02 9:49 ` Avi Kivity
2010-06-02 10:04 ` Joerg Roedel
2010-06-02 10:09 ` Michael S. Tsirkin
2010-06-02 11:21 ` Avi Kivity
2010-06-02 16:53 ` Chris Wright
2010-06-06 13:44 ` Avi Kivity
2010-06-02 10:15 ` Michael S. Tsirkin
2010-06-02 10:26 ` Joerg Roedel
2010-06-01 21:26 ` Tom Lyon
2010-06-02 2:59 ` Avi Kivity
2010-06-02 5:29 ` Chris Wright
2010-06-02 5:40 ` Avi Kivity
2010-06-02 4:29 ` Alex Williamson
2010-06-02 4:59 ` Tom Lyon
2010-06-02 5:08 ` Avi Kivity
2010-06-02 9:53 ` Joerg Roedel
2010-06-02 9:42 ` Joerg Roedel
2010-06-02 9:50 ` Avi Kivity
2010-06-02 9:53 ` Michael S. Tsirkin
2010-06-02 10:19 ` Joerg Roedel
2010-06-02 10:21 ` Michael S. Tsirkin
2010-06-02 10:35 ` Joerg Roedel
2010-06-02 10:38 ` Michael S. Tsirkin
2010-06-02 11:12 ` Joerg Roedel
2010-06-02 11:21 ` Michael S. Tsirkin [this message]
2010-06-02 12:19 ` Joerg Roedel
2010-06-02 12:25 ` Avi Kivity
2010-06-02 12:50 ` Joerg Roedel
2010-06-02 13:06 ` Avi Kivity
2010-06-02 13:53 ` Joerg Roedel
2010-06-02 13:17 ` Michael S. Tsirkin
2010-06-02 14:01 ` Joerg Roedel
2010-06-02 12:34 ` Michael S. Tsirkin
2010-06-02 13:02 ` Joerg Roedel
2010-06-02 17:46 ` Chris Wright
2010-06-02 18:09 ` Tom Lyon
2010-06-02 19:46 ` Joerg Roedel
2010-06-03 6:23 ` Avi Kivity
2010-06-03 21:41 ` Tom Lyon
2010-06-06 9:54 ` Michael S. Tsirkin
2010-06-07 19:01 ` Tom Lyon
2010-06-08 21:22 ` Michael S. Tsirkin
2010-06-02 10:44 ` Michael S. Tsirkin
2010-05-30 12:59 ` Avi Kivity
2010-05-31 17:17 ` Alan Cox
2010-06-01 21:29 ` Tom Lyon
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=20100602112100.GA29697@redhat.com \
--to=mst@redhat.com \
--cc=aafabbri@cisco.com \
--cc=avi@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=gregkh@suse.de \
--cc=hjk@linutronix.de \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pugs@cisco.com \
--cc=scofeldm@cisco.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.