From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neo Jia Subject: Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver Date: Tue, 16 Aug 2016 14:17:28 -0700 Message-ID: <20160816211728.GA25389@nvidia.com> References: <1470251034-1555-2-git-send-email-kwankhede@nvidia.com> <20160809130022.67784f62@t450s.home> <47977462-4a68-f973-a2b8-4c40fbfc9451@nvidia.com> <20160812151608.0db20258@t450s.home> <361a1668-ca11-c46c-7bf6-19c36e703a2d@nvidia.com> <20160815195907.GA14876@nvidia.com> <20160815164741.3bc97ddc@t450s.home> <20160816203006.GB24304@nvidia.com> <20160816145103.04017997@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Tian, Kevin" , "Song, Jike" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Kirti Wankhede , "kraxel@redhat.com" , "pbonzini@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" To: Alex Williamson Return-path: Received: from hqemgate16.nvidia.com ([216.228.121.65]:16192 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752034AbcHPVRa (ORCPT ); Tue, 16 Aug 2016 17:17:30 -0400 Content-Disposition: inline In-Reply-To: <20160816145103.04017997@t450s.home> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Aug 16, 2016 at 02:51:03PM -0600, Alex Williamson wrote: > On Tue, 16 Aug 2016 13:30:06 -0700 > Neo Jia 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 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, Agree. We will adopt the similar syntax and support _show() function. Thanks, Neo > > Alex