Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161894AbbKTCrm (ORCPT ); Thu, 19 Nov 2015 21:47:42 -0500 Received: from mga03.intel.com ([134.134.136.65]:18023 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161088AbbKTCrl (ORCPT ); Thu, 19 Nov 2015 21:47:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,320,1444719600"; d="scan'208";a="855397867" Message-ID: <564E899E.4090904@intel.com> Date: Fri, 20 Nov 2015 10:46:54 +0800 From: Jike Song User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paolo Bonzini CC: Gerd Hoffmann , "Tian, Kevin" , Alex Williamson , "xen-devel@lists.xen.org" , "igvt-g@ml01.01.org" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "White, Michael L" , "Dong, Eddie" , "Li, Susie" , "Cowperthwaite, David J" , "Reddy, Raghuveer" , "Zhu, Libo" , "Zhou, Chao" , "Wang, Hongbo" , "Lv, Zhiyuan" , qemu-devel Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447922452.25140.39.camel@redhat.com> <564DADCC.2030702@redhat.com> In-Reply-To: <564DADCC.2030702@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1565 Lines: 44 On 11/19/2015 07:09 PM, Paolo Bonzini wrote: > On 19/11/2015 09:40, Gerd Hoffmann wrote: >>>> But this code should be >>>> minor to be maintained in libvirt. >> As far I know libvirt only needs to discover those devices. If they >> look like sr/iov devices in sysfs this might work without any changes to >> libvirt. > > I don't think they will look like SR/IOV devices. > > The interface may look a little like the sysfs interface that GVT-g is > already using. However, it should at least be extended to support > multiple vGPUs in a single VM. This might not be possible for Intel > integrated graphics, but it should definitely be possible for discrete > graphics cards. Didn't hear about multiple vGPUs for a single VM before. Yes If we expect same vGPU interfaces for different vendors, abstraction and vendor specific stuff should be implemented. > Another nit is that the VM id should probably be replaced by a UUID > (because it's too easy to stumble on an existing VM id), assuming a VM > id is needed at all. For the last assumption, yes, a VM id is not necessary for gvt-g, it's only a temporary implementation. As long as libvirt is used, UUID should be enough for gvt-g. However, UUID is not mandatory? What should we do if user don't specify an UUID in QEMU cmdline? > > Paolo > -- Thanks, Jike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/