qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).