From: Alex Williamson <alex.williamson@redhat.com>
To: Neo Jia <cjia@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Song, Jike" <jike.song@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver
Date: Tue, 16 Aug 2016 14:51:03 -0600 [thread overview]
Message-ID: <20160816145103.04017997@t450s.home> (raw)
In-Reply-To: <20160816203006.GB24304@nvidia.com>
On Tue, 16 Aug 2016 13:30:06 -0700
Neo Jia <cjia@nvidia.com> wrote:
> On Mon, Aug 15, 2016 at 04:47:41PM -0600, Alex Williamson wrote:
> > On Mon, 15 Aug 2016 12:59:08 -0700
> > Neo Jia <cjia@nvidia.com> wrote:
> >
> > > > > >
> > > > > > I'm not sure a comma separated list makes sense here, for both
> > > > > > simplicity in the kernel and more fine grained error reporting, we
> > > > > > probably want to start/stop them individually. Actually, why is it
> > > > > > that we can't use the mediated device being opened and released to
> > > > > > automatically signal to the backend vendor driver to commit and release
> > > > > > resources? I don't fully understand why userspace needs this interface.
> > > >
> >
> > That doesn't give an individual user the ability to stop and start
> > their devices though, because in order for a user to have write
> > permissions there, they get permission to DoS other users by pumping
> > arbitrary UUIDs into those files. By placing start/stop per mdev, we
> > have mdev level granularity of granting start/stop privileges. Really
> > though, do we want QEMU fumbling around through sysfs or do we want an
> > interface through the vfio API to perform start/stop? Thanks,
>
> Hi Alex,
>
> I think those two suggests make sense, so we will move the "start/stop"
> under mdev sysfs.
>
> This will be incorporated in our next v7 patch and by doing that, it will make
> the locking scheme easier.
Thanks Neo. Also note that the semantics change when we move to per
device control. It would be redundant to 'echo $UUID' into a start
file which only controls a single device. So that means we probably
just want an 'echo 1'. But if we can 'echo 1' then we can also 'echo
0', so we can reduce this to a single sysfs file. Sysfs already has a
common interface for starting and stopping devices, the "online" file.
So I think we should probably move in that direction. Additionally, an
"online" file should support a _show() function, so if we have an Intel
vGPU that perhaps does not need start/stop support, online could report
"1" after create to show that it's already online, possibly even
generate an error trying to change the online state. Thanks,
Alex
next prev parent reply other threads:[~2016-08-16 20:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 19:03 [Qemu-devel] [PATCH v6 0/4] Add Mediated device support Kirti Wankhede
2016-08-03 19:03 ` [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver Kirti Wankhede
2016-08-04 7:21 ` Tian, Kevin
2016-08-05 6:13 ` Kirti Wankhede
2016-08-15 9:15 ` Tian, Kevin
2016-08-09 19:00 ` Alex Williamson
2016-08-12 18:44 ` Kirti Wankhede
2016-08-12 21:16 ` Alex Williamson
2016-08-13 0:37 ` Kirti Wankhede
2016-08-15 9:38 ` Tian, Kevin
2016-08-15 15:59 ` Alex Williamson
2016-08-15 22:09 ` Neo Jia
2016-08-15 22:52 ` Alex Williamson
2016-08-15 23:23 ` Neo Jia
2016-08-16 0:49 ` Tian, Kevin
2016-08-15 19:59 ` Neo Jia
2016-08-15 22:47 ` Alex Williamson
2016-08-15 23:54 ` Neo Jia
2016-08-16 0:18 ` Tian, Kevin
2016-08-16 20:30 ` Neo Jia
2016-08-16 20:51 ` Alex Williamson [this message]
2016-08-16 21:17 ` Neo Jia
2016-08-16 0:30 ` Tian, Kevin
2016-08-16 3:45 ` Neo Jia
2016-08-16 3:50 ` Tian, Kevin
2016-08-16 4:16 ` Neo Jia
2016-08-16 4:52 ` Tian, Kevin
2016-08-16 5:43 ` Neo Jia
2016-08-16 5:58 ` Tian, Kevin
2016-08-16 6:13 ` Neo Jia
2016-08-16 21:03 ` Alex Williamson
2016-08-16 12:49 ` Alex Williamson
2016-08-03 19:03 ` [Qemu-devel] [PATCH v6 2/4] vfio: VFIO driver for mediated PCI device Kirti Wankhede
2016-08-03 21:03 ` kbuild test robot
2016-08-04 0:19 ` kbuild test robot
2016-08-09 19:00 ` Alex Williamson
2016-08-10 21:23 ` Kirti Wankhede
2016-08-10 23:00 ` Alex Williamson
2016-08-11 15:59 ` Kirti Wankhede
2016-08-11 16:24 ` Alex Williamson
2016-08-11 17:46 ` Kirti Wankhede
2016-08-11 18:43 ` Alex Williamson
2016-08-12 17:57 ` Kirti Wankhede
2016-08-12 21:25 ` Alex Williamson
2016-08-13 0:42 ` Kirti Wankhede
2016-08-03 19:03 ` [Qemu-devel] [PATCH v6 3/4] vfio iommu: Add support for mediated devices Kirti Wankhede
2016-08-09 19:00 ` Alex Williamson
2016-08-11 14:22 ` Kirti Wankhede
2016-08-11 16:28 ` Alex Williamson
2016-08-03 19:03 ` [Qemu-devel] [PATCH v6 4/4] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-08-04 7:31 ` Tian, Kevin
2016-08-05 7:45 ` Kirti Wankhede
2016-08-24 22:36 ` Daniel P. Berrange
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=20160816145103.04017997@t450s.home \
--to=alex.williamson@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=cjia@nvidia.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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 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).