From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhhdq-0001Fm-KB for qemu-devel@nongnu.org; Wed, 07 Sep 2016 14:32:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhhdl-0000qe-Ft for qemu-devel@nongnu.org; Wed, 07 Sep 2016 14:32:09 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:1874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhhdl-0000qY-85 for qemu-devel@nongnu.org; Wed, 07 Sep 2016 14:32:05 -0400 Date: Wed, 7 Sep 2016 11:32:02 -0700 From: Neo Jia Message-ID: <20160907183202.GA17393@nvidia.com> References: <2a195ed1-f6aa-ffab-3f5c-4121de264d05@redhat.com> <20160906114030.3c9a0162@t450s.home> <3f35c9e0-859e-0175-4362-8674a0acb857@nvidia.com> <20160906152858.040e557d@t450s.home> <9276a8a9-02dd-57dd-ba19-cbac5a0d6f3a@nvidia.com> <20160907104456.0e8d0477@t450s.home> <20160907181738.GA16610@nvidia.com> <20160907182719.GF14110@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160907182719.GF14110@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Alex Williamson , "Song, Jike" , "kvm@vger.kernel.org" , "libvir-list@redhat.com" , Michal Privoznik , "Tian, Kevin" , "qemu-devel@nongnu.org" , Kirti Wankhede , "kraxel@redhat.com" , Laine Stump , Paolo Bonzini , "bjsdjshi@linux.vnet.ibm.com" On Wed, Sep 07, 2016 at 07:27:19PM +0100, Daniel P. Berrange wrote: > On Wed, Sep 07, 2016 at 11:17:39AM -0700, Neo Jia wrote: > > On Wed, Sep 07, 2016 at 10:44:56AM -0600, Alex Williamson wrote: > > > On Wed, 7 Sep 2016 21:45:31 +0530 > > > Kirti Wankhede wrote: > > > > > > > To hot-plug mdev device to a domain in which there is already a mdev > > > > device assigned, mdev device should be created with same group number as > > > > the existing devices are and then hot-plug it. If there is no mdev > > > > device in that domain, then group number should be a unique number. > > > > > > > > This simplifies the mdev grouping and also provide flexibility for > > > > vendor driver implementation. > > > > > > The 'start' operation for NVIDIA mdev devices allocate peer-to-peer > > > resources between mdev devices. Does this not represent some degree of > > > an isolation hole between those devices? Will peer-to-peer DMA between > > > devices honor the guest IOVA when mdev devices are placed into separate > > > address spaces, such as possible with vIOMMU? > > > > Hi Alex, > > > > In reality, the p2p operation will only work under same translation domain. > > > > As we are discussing the multiple mdev per VM use cases, I think we probably > > should not just limit it for p2p operation. > > > > So, in general, the NVIDIA vGPU device model's requirement is to know/register > > all mdevs per VM before opening any those mdev devices. > > It concerns me that if we bake this rule into the sysfs interface, > then it feels like we're making life very hard for future support > for hotplug / unplug of mdevs to running VMs. Hi Daniel, I don't think the grouping will stop anybody from supporting hotplug / unplug at least from syntax point of view. > > Conversely, if we can solve the hotplug/unplug problem, then we > potentially would not need this grouping concept. I think Kirti has also mentioned about hotplug support in her proposal, do you mind to comment on that thread so I can think if I have missed anything? Thanks, Neo > > I'd hate us to do all this complex work to group multiple mdevs per > VM only to throw it away later when we hotplug support is made to > work. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|