From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE63o-0000lZ-Qb for qemu-devel@nongnu.org; Wed, 21 Jan 2015 19:55:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YE63l-0006T9-LY for qemu-devel@nongnu.org; Wed, 21 Jan 2015 19:55:48 -0500 Received: from mga02.intel.com ([134.134.136.20]:41683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE63l-0006Sx-Fu for qemu-devel@nongnu.org; Wed, 21 Jan 2015 19:55:45 -0500 Message-ID: <54C04A8E.30506@intel.com> Date: Thu, 22 Jan 2015 08:55:42 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <1421824792-3925-1-git-send-email-tiejun.chen@intel.com> <21695.36752.122911.770104@mariner.uk.xensource.com> <1421841376.13271.5.camel@citrix.com> In-Reply-To: <1421841376.13271.5.camel@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Campbell , Ian Jackson Cc: qemu-devel@nongnu.org, wei.liu2@citrix.com, kraxel@redhat.com, xen-devel@lists.xen.org On 2015/1/21 19:56, Ian Campbell wrote: > On Wed, 2015-01-21 at 11:37 +0000, Ian Jackson wrote: >> Tiejun Chen writes ("[RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough"): >>> When we're working to support IGD GFX passthrough with qemu >>> upstream, instead of "-gfx_passthru" we'd like to make that >>> a machine option, "-machine xxx,gfx_passthru=on". This need >>> to bring several changes on tool side. >> >> Has the corresponding patch to qemu-upstream been accepted yet ? >> >> I'd like to see a confirmation from the qemu side that this is going >> into their tree and that the command-line option syntax has been >> agreed. > > Do we need to detect old vs. new qemu to know when this option is valid? Do you mean we should introduce these two options into qemu upstream at the same time? Here I just keep that new option, and that old is gone. Thanks Tiejun